- Fri May 15, 2020 8:04 am
#215327
Hi,
I've been trying to make two sparkfun devices (either apollo3 blue or artemis nano) communicate through BLE.
I've started with the Amdtp example from SDK 2.2.0 as well as the Cordio Tag example. My current code has one server which advertises when not connected, and one client which will scan, connect to the server, send 500 messages, disconnect, then repeat.
On top of managing the BLE communication, I also want my client device to sample data using a ctimer interrupt. However, while experimenting with different clock configurations, I've noticed that one of the devices sometimes freezes.
Here is the slightly modified configuration of the clocks in the examples from the SDK:
In both cases, the code behaves exactly the same, I've edited the time tracking to take into account the new frequency of the clock.
Here's what my main loop looks like:
Here are some additional details that might help:
Thanks
I've been trying to make two sparkfun devices (either apollo3 blue or artemis nano) communicate through BLE.
I've started with the Amdtp example from SDK 2.2.0 as well as the Cordio Tag example. My current code has one server which advertises when not connected, and one client which will scan, connect to the server, send 500 messages, disconnect, then repeat.
On top of managing the BLE communication, I also want my client device to sample data using a ctimer interrupt. However, while experimenting with different clock configurations, I've noticed that one of the devices sometimes freezes.
Here is the slightly modified configuration of the clocks in the examples from the SDK:
Code: Select all
This configuration seems to work well, however if I use the XT clock at 32kHz (AM_HAL_CTIMER_XT_32_768KHZ) instead of the LFRC at 512Hz (AM_HAL_CTIMER_LFRC_512HZ), then I experience many freezes. By freeze I mean that the device doesn't go through the main loop anymore. It seems to never wake up from the deep sleep.void scheduler_timer_init(void) {
// config for timer A: continuous timer that serves for time tracking
am_hal_ctimer_clear(0, AM_HAL_CTIMER_TIMERA);
am_hal_ctimer_config_single(0, AM_HAL_CTIMER_TIMERA, (AM_HAL_CTIMER_FN_CONTINUOUS | AM_HAL_CTIMER_LFRC_512HZ));
// config for timer B: one-shot to provide interrupts for timed events
am_hal_ctimer_clear(0, AM_HAL_CTIMER_TIMERB);
am_hal_ctimer_config_single(0, AM_HAL_CTIMER_TIMERB, (AM_HAL_CTIMER_FN_ONCE | AM_HAL_CTIMER_INT_ENABLE | AM_HAL_CTIMER_LFRC_512HZ));
am_hal_ctimer_int_clear(AM_HAL_CTIMER_INT_TIMERB0);
am_hal_ctimer_int_enable(AM_HAL_CTIMER_INT_TIMERB0);
NVIC_EnableIRQ(CTIMER_IRQn);
am_hal_interrupt_master_enable();
am_hal_ctimer_start(0, AM_HAL_CTIMER_TIMERA);
}
In both cases, the code behaves exactly the same, I've edited the time tracking to take into account the new frequency of the clock.
Here's what my main loop looks like:
Code: Select all
There are a few things I don't quite understand:
while (1) {
// Calculate the elapsed time from our free-running timer, and update
// the software timers in the WSF scheduler.
update_scheduler_timers();
wsfOsDispatcher();
// Enable an interrupt to wake us up next time we have a scheduled event.
set_next_wakeup();
am_hal_interrupt_master_disable();
// Check to see if the WSF routines are ready to go to sleep.
uint8_t readyToSleep = wsfOsReadyToSleep();
am_hal_interrupt_master_enable();
if (readyToSleep) {
am_hal_sysctrl_sleep(AM_HAL_SYSCTRL_SLEEP_DEEP);
}
}
- I've noticed that the source code from the Cordio Tag example calls am_hal_interrupt_master_enable() after the deep sleep command. Since interrupts are disabled when calling am_hal_sysctrl_sleep(AM_HAL_SYSCTRL_SLEEP_DEEP), doesn't that mean that the ctimer won't wake it up?
- am_hal_interrupt_master_disable() doesn't seem to prevent BLE interrupts at all, am_ble_isr(), can be called right between am_hal_interrupt_master_disable() and am_hal_interrupt_master_enable().
Here are some additional details that might help:
- Most often, the client freezes first, while sending messages. The server sometimes doesn't detect that the client froze and thinks that it is still connected. Even though it is supposed to disconnect automatically after 5 seconds of inactivity from the client.
- The freezes occur around 15 minutes after starting the device while using the XT clock.
- Once a device freezes, the other one never freezes, so the freezes seem to be related to BLE.
Thanks