[Mark Ruys]

For the xDot:

IWDG_HandleTypeDef hiwdg;

...

    // Enable watchdog. Clock is 37 KHz, reload is 0xfff, prescaler 256, so we need to
    // reset the watchdog within 0xfff / 37k * 256 seconds = 28 seconds.
    hiwdg.Instance = IWDG;
    hiwdg.Init.Prescaler = IWDG_PRESCALER_256;
    hiwdg.Init.Reload = 0xfff;
    if ( HAL_IWDG_Init(&hiwdg) != HAL_OK ) {
        // Error
    }

Call HAL_IWDG_Refresh(&hiwdg) to reset the watchdog.

Note that this watchdog can’t be disabled and will keep running in sleep mode (stop, not sure about standby).

[Mark Ruys]

You use stop mode (sleep), then you get these “Mac: ResetState” errors. Run the code from http://www.multitech.net/developer/forums/topic/timer-unreliable-after-a-dot-sleep/ just after the dot->sleep(.., .., false). Always.

I can’t see from your log, but you need at least 3 seconds between join attempts, and probably also between uplink messages.

[Mark Ruys]

Upload a hello world application to your xDot which changes the join from AUTO_OTA to OTA. Run it once, then flash back the AT firmware.

[Mark Ruys]

Some experiences which might help you:

– [US915] If configure the frequency sub band to 0 and enable ADR (a must on public networks), and when you joined successfully, upload a series of consecutive confirmed messages until you get an acknowledgement. You’ll get a new channel mask too through the ADR mac command LinkADRReq, so now you can switch to link checks. This way you can get your xDot working on a limited 8 channel gateway relatively easily.
– Don’t use deep sleep in combination with ADR, the xDot forgets about the ADR after it comes back from deep sleep.
– Beware that after a normal sleep (stop), timers run at the wrong pace, check out my post http://www.multitech.net/developer/forums/topic/timer-unreliable-after-a-dot-sleep/ on how to fix that.
– Wait at least 3 seconds (and at least dot->getNextTxMs() msecs) between join attempts (so probably stay away from AUTO_OTA). Otherwise you may get strange “Link is busy” errors, sometimes even hanging the xDot. I guess this holds for normal uplink messages too.
– If you use normal sleep (stop) and the ADC, call this code:

void fixADC() {
RCC_OscInitTypeDef RCC_OscInitStruct;
HAL_RCC_GetOscConfig(&RCC_OscInitStruct);
if ( RCC_OscInitStruct.HSIState != RCC_HSI_ON ) {
RCC_OscInitStruct.HSIState = RCC_HSI_ON;
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
HAL_StatusTypeDef ret = HAL_RCC_OscConfig(&RCC_OscInitStruct);
if ( ret == HAL_OK ) {
logWarning(“Fixed the HSI to clock the ADC”);
}
else {
logError(“Failed to fix the HSI to clock the ADC: %d”, ret);
}
}
}

Cheers, Mark

[Mark Ruys]

I’m sorry, it appeared to be a hardware issue after all. No bug.

Mark

[Mark Ruys]

mbed-os 5.3.2 (133), libxDot 2.0.16-7-ga61aab1-mbed133

and

mbed-os 5.4.2 (139), libxDot 2.0.17-mbed139

Didn’t try other versions.

[Mark Ruys]

Okay, found a work around to get the clock running at the proper speed.

#include "hal_tick.h"
#include "mbed_rtx.h"

...

    uint32_t us_ticker = us_ticker_read();

    int delay = 1;
    dot->sleep(delay, mDot::RTC_ALARM, false /*no deepsleep*/);
    us_ticker += delay * 1000000;

    if ( TIM_MST->PSC != OS_CLOCK / 1000000 - 1 ) {
        TIM_MST->PSC = OS_CLOCK / 1000000 - 1;
        TIM_MST->EGR = TIM_EVENTSOURCE_UPDATE;
        while ( TIM_MST->EGR & ~TIM_EVENTSOURCE_UPDATE ) {};
        TIM_MST->CNT = us_ticker;
    }

This fixes the issue that after a dot->sleep() the µsec timer has a prescaler of (10 – 1) instead of (32 – 1).

Cheers, Mark

[Mark Ruys]

Well it’s actually an xDot. And I erred, as getStandbyFlag() is always false instead of true in my case.

But now I understand why. I assumed that when you power cycle the MCU while in a deep sleep, it will restart from scratch. Likewise after you perform a hard reset. What I missed is that the session is stored in some persistent memory, preserving the session this. Only reflashing will remove this session state (or eraseFlash() I guess). And only then getStandbyFlag() will be false.

The STM32L151CC datasheet mentions a 8 KB EEPROM and 128 bytes backup registers. The nvmWrite() and nvmRead() from mDot.h gave access to 6 KB. So I guess that the ‘missing’ 2 KB is used by the xDot library to store the session state.

[Mark Ruys]

Okay, it was a bit complicated and not an xDot specific issue: https://developer.mbed.org/questions/77516/Interrupt-driven-comparator/.

As for COMP2, that is not available for the xDot as this comparator can’t be routed to pins which are available for us. Luckily, COMP1 will do the job I need to do.

Cheers, Mark

[Mark Ruys]

I completely overlooked that the RTC survives a deepsleep. So time() is just what I need, thanks.

We expect our sensors to go to deepsleep about 50.000 times during their life time. EEPROM handles minimal 300.000 erase/write cycles, so we’re good 🙂

In our case I can determine the cause of the wake up by checking the WAKE pin.

Best,
Mark

[Mark Ruys]

I’m afraid the url of the repository dropped in my post, it’s: https://developer.mbed.org/teams/MultiTech/code/libxDot-Custom/.

Okay, so a single xDot for multiple regions is asking too much. But do understand correctly that using the libxDot-Custom, you can use a say EU xDot and flash it with an 915 US firmware? And vice versa? Of course the antenna must be designed to match both frequencies. Or are there other gotcha?

Cheers,

Mark

[Mark Ruys]

I upgraded ST-Link from J24 to J28. After resetting the board, OpenOCD 0.10.0 could connect. So now I’m running gdb on a Mac without a hitch. Isn’t that awesome!

Best, Mark

[Mark Ruys]

Okay, I got a bit further. For OpenOCD 0.10.0, you don’t need the line “source [find interface/stlink-v2.cfg]” anymore in f411re.cfg.

Then:

Yavin4:mDot-Examples markr$ openocd -f ./f411re.cfg 
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.230039
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f4x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f4x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 300ms

So a lot already goes okay!

Raising the debug level, part of the log:

Info : 259 5 core.c:1386 adapter_init(): clock speed 1800 kHz
Debug: 260 5 openocd.c:140 handle_init_command(): Debug Adapter init complete
Debug: 261 5 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_transport init
Debug: 262 5 command.c:143 script_debug(): command - ocd_transport ocd_transport init
Debug: 264 5 transport.c:239 handle_transport_init(): handle_transport_init
Debug: 265 5 hla_transport.c:152 hl_transport_init(): hl_transport_init
Debug: 266 5 hla_transport.c:169 hl_transport_init(): current transport hla_swd
Debug: 267 5 hla_interface.c:42 hl_interface_open(): hl_interface_open
Debug: 268 5 hla_layout.c:40 hl_layout_open(): hl_layout_open
Debug: 269 5 stlink_usb.c:1642 stlink_usb_open(): stlink_usb_open
Debug: 270 5 stlink_usb.c:1659 stlink_usb_open(): transport: 1 vid: 0x0483 pid: 0x374b serial: 
Info : 271 11 stlink_usb.c:563 stlink_usb_version(): STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : 272 11 stlink_usb.c:1770 stlink_usb_open(): using stlink api v2
Debug: 273 11 stlink_usb.c:762 stlink_usb_init_mode(): MODE: 0x02
Info : 274 12 stlink_usb.c:595 stlink_usb_check_voltage(): Target voltage: 3.231621
Debug: 275 12 stlink_usb.c:817 stlink_usb_init_mode(): MODE: 0x01
Debug: 276 12 stlink_usb.c:442 stlink_usb_error_check(): unknown/unexpected STLINK status code 0x9
Error: 277 12 stlink_usb.c:1779 stlink_usb_open(): init mode failed (unable to connect to the target)

Perhaps I should go back to 0.9.0 anyway. Or might it have to do with a low-power state of the mDot. Let’s give it a call for now.

[Mark Ruys]

Yeah I saw this post. Looks useful for me!

I’m cheating a bit as I try to run OpenOCD on a Mac. Also not version 0.9.0, but 0.10.0.

So I should use interface/stlink-v2-1.cfg for this board? And this is over USB, not by using a hardware ST-Link?

Yavin4:mDot-Examples markr$ openocd -f ./f411re.cfg -f ./gdb.cfg -c "init; halt"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Error: already specified hl_layout stlink
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Hm, I have to spend some more time on this to get it working.

[Mark Ruys]

Okay, I see, nice!

Then I need the ADC_VREF PinName, which entered mbed-os only at version 5.2 (. Now for libxDot-mbed5, we need 5.1.5, according to its commit log.

So how do I solve that?
– Ignore the warning and use 5.2.0
– Use libxDot-dev-mbed5 (but we’re developing a product, so is that wise)
– Patch 5.1.5 which ADC internal commits from 5.2.0

What do you advise?

[Mark Ruys]

Thought so, but asked anyway, better safe than sorry 😉

Thanks for the follow up Mike.

[Mark Ruys]

Sounds great guys. This kind of support is why we’ve chosen the xDot above other competitive modules 😉

Thanks & all the best,
Mark

[Mark Ruys]

Dear Kaz Ola,

I have more or less the same questions. JP5 on the xDot seems to have no impact on the current measurements. What is the purpose of JP5?

Furthermore, I measure 8 uA in deep sleep, instead 2 uA from the datasheet. Did you manage to lower your power consumption to 2 uA? Do you know what explains the difference?

Best,
Mark

[Mark Ruys]

Okay, I did found the JP2 JTAG schematics (it’s on pg 51 of the devel guide). It’s purpose is to access and flash the devel kits Cortex-M4, not the xDot. Now I understand that the xDot support flashing/debugging over SWD.

So then I’m back at these questions:
– Can anyone advise on a SWD programmer (for development).
– Is it possible to add JTAG to the xDot (and if so, how?).

Thanks again. Mark

[Author]

Posts