Disabling all low power modes on Duo [SOLVED]


#1

Other than modifying the RedBear Duo firmware code, is there a way to disable all low power settings from a Sketch? I run my Duos using 5v power supply and do not need the low power capabilities.

Does this disable or enable them in debugger/openOCD?

# DBGMCU_CR |= DBG_STANDBY | DBG_STOP | DBG_SLEEP
mmw 0xE0042004 0x00000007 0

Would it be possible to get the openOCD scripts RedBear uses for STM32F2x.cfg and redbearduo.cfg? I am using the ones from:

But I still have something wrong as I am getting disconnect/reconnects while trying to debug:

Error: jtag status contains invalid mode value - communication failure
Polling target stm32f2x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 6300ms

Looking for additional suggestions as well.

Thanks,

Bill


Debugging against the RedBear Duo
#2

The Duo dose not enable any low power mode by default. The redbearduo.cfg is a board level config file, it has included the interface and target config files.


#3

I met the same error as you did. Still looking into it…


#4

I am too. Still no luck here.


#5

I can confirm that using RBLink for debugging will not work using:

Visual Studio 2012, VisualGDB, openOCD.
openOCD, arm-none-eabi-gdb

I have tried the VisualGDB sample app and the debug version of my application build using RedBear Duo firmware.

I can upload using either RBLink, direct to the Duo using DFU-uti and the ST-Link Util.

Development is halted. This issue is critical.

Has anyone done debugging of Duo using ST-Link USB dongle directly to SWDIO and SWCLK pins without RBlink?


#6

After searching for this error:

Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f2x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 300ms

I read where someone suggested increasing workspace size. I changed:

set WORKAREASIZE 0x4000

to

set WORKAREASIZE 0x8000

I am now able to debug the sample application. Going to try testing my debug version now.


#7

Using only the following to debug my app:

openocd.exe -f redbearduo.cfg -f stm32f2x.cfg -c “gdb_port 3333”
arm-none-eabi-gdb -ex “target remote localhost:3333” …\build\target\user-part\platform-88-m\user-part.elf

I still get the same errors as previously described. The redbearduo.cfg has been tried with both workspace settings.


#8

I have now setup VisualGDB to build a debug version of my app and it is runnning. I have not setup system-part1 or system-part2 to build in Visual GDB yet, so I am still using the RedBear Firmware versions from GitHub, built for debugging as well.

And yes, still getting the same problem with disconnecting and the same errors. App is running though, so I believe it has to be something with ST-Link in RBLink causing the problem. Or maybe the firmware. IDK.

While waiting for help from RedBear, I will setup the system-part1 & 2 to build in VisualGDB as well. I really like using Visual Studio/GDB for debugging so far.


#9

HardFault - SOS + 13 red blinks = StackOverflow. Unfortunately, could not catch it for two reasons - 1: was not debugging system-part2, 2: had no breakpoint set for client.write() or hardfault handler as suggested by guohui in:

Off to complete setting up system-part1 & 2 in VisualGDB and try again.


#10

Still unable to keep connection to RBLink.

Any other suggestions appreciated.


#11

Hi @billskeen68,

Good news! I can now connect to target and make the duo ‘continue’. Steps to produce:

  1. Pull the latest branch duo on github
  2. Navigate to the “modules” folder
  3. Run make PLATFORM=duo PARTICLE_DEVELOP=1 USE_SWD_JATG=y
  4. Upload the compiled system-part1, system-part2 and user part to Duo using dfu-util
  5. Run openocd -f redbearduo.cfg -c "gdb_port 3333" -c "$_TARGETNAME configure -rtos FreeRTOS":
  6. Open another terminal and run arm-none-eabi-gdb system-part2.elf. Then connect to gdbserver using target remote localhost:3333 and halt the target MCU by mon reset halt:
  7. Type continue:

I haven’t set any breakpoints, so it runs forever.


#12

Still getting same error in openOCD command window. Could it be the DEBUG_BUILD=y switch?

Info : Previous state query failed, trying to reconnect
Error: jtag status contains invalid mode value - communication failure
Polling target stm32f2x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 6300ms


#13

Finally figured out that using RGB led while the Duo is in the RBLink will cause the debugger to disconnect. D7 is shared by the led and JTAG_TMS pin.

I use the Led to indicate when connecting to WiFi and when all BLE devices are connected, like the BLE Controller sample app does.

Commented out all calls to RGB and it has been connected for over an hour now.

This issue is solved.

Back to regular scheduled debugging of hard fault and more VisualGDB configuration. :smile:


#14

Two issues:

  1. make complains about the arm-none-eabi-gcc and requires 5.3.1 or later.

make[1]: arm-none-eabi-gcc: Command not found
…/build/arm-tools.mk:41: *** "ARM gcc version 5.3.1 or later required, but found ". Stop.

So I edited ~/Downloads/firmware-duo/build/arm-tools.mk with

GCC_PREFIX := ~/Library/Arduino15/packages/AZ3166/tools/arm-none-eabi-gcc/5_4-2016q3/bin/arm-none-eabi-
  1. Build fails with the following error:

In file included from …/platform/MCU/STM32F2xx/SPARK_Firmware_Driver/inc/platform_system_flags.h:16:0,
from ./src/duo/dct_hal.h:16,
from src/stm32f2xx/deviceid_hal.c:30:
…/services/inc/static_assert.h:20:52: error: size of array ‘assert_size_complete_dct’ is negative
#define STATIC_ASSERT(name,condition) typedef char assert_##name[(condition)?0:-1]
^
./src/duo/dct_hal.h:27:1: note: in expansion of macro ‘STATIC_ASSERT’
STATIC_ASSERT(size_complete_dct, (sizeof(complete_dct_t)<16384));
^
make[3]: *** […/build/target/hal/platform-88-m/./src/stm32f2xx/deviceid_hal.o] Error 1
make[2]: *** [hal] Error 2
make[1]: *** [~/Downloads/firmware-duo/modules/duo/system-part1/makefile] Error 2

Please provide a full procedure as per Debugging against the RedBear Duo.


#15

Hi @reivilo, The latest duo branch is catching up with the Particle firmware develop branch, lots of features, bug fixes and enhancement are to be merged. So do not try to build the latest branch, unless we announce a new release.

Best regards,
guohui