1 month ago
different behavior on DA14531 when burning OTP
Posted bypierrej@kickma…20分 6repliesHello,
i'm trying develop an application with DA14531 to control RGB led by BLE.
The DA14531 is set in BYPASS mode HW-wise and the CFG_POWER_MODE_BYPASS is defined. CFG_DEVELOPMENT_DEBUG is defined also.
Led are wired on pin 0, 10 and 11. (RST and SWIO are disabled by the firmware)
a button is wired on pin 6.
Led are controlled by pwm using timer 2.
The button is linked to an interrupt setting the duty cycle of the pwm based on a BLE characteristic for 10 sec.
Default sleep mode is set to ARCH_EXT_SLEEP_ON.
Software starts with LED turned off. The button interrupt disable the sleep mode, set the led's duty cycle and enable a callback on timer 0.
The callback increments a counter while the 10 seconds aren't reached and do the following when the 10seconds mark is reached :
- turn off the led
- put the system into deep sleep without OTP copy
- turn off timer 0
The code is working perfectly when flashed through JTAG in the sysRam, however when burning the OTP, the behavior is strange :
- BLE工作正常、特点be written by a remote device and the values are retained over time.
- The Leds are flashing every second or so when the BLE is advertising.
- The leds are flickering very fast when connection and service discovery is done.
- The leds are turned on when connection is finished.
- Disconnecting the remote device restart the flashing while the advertising is started again.
- The button does not light the led.
- The Leds colors aren't related to the values stored in the BLE characteristic.
OTP burn is done via SmartSnippets Toolbox and the header is the one proposed by the toolbox without modification exept for Application flags 1 and 2 which are set to yes.
I have been able to reproduce this exact behavior while flashing in sysRam by "forgetting" to set CTRL_SYS_REG[DEBUGGER_ENABLE] to 0 and disconnecting the jtag through the flashing software.
Note that it only reproduce the behavior if the jtag is disconnected via a software mean (close debug option when flashing). If i unplug the jtag while it's connection is up, everything works fine.
1 month ago
>>>When the device is booting from System-Ram, you mentioned that the application code is working perfectly. Did you test it with or without the debugger attached?
Both, and it works fine in both cases.
>>>So, with statement you mean that if the CTRL_SYS_REG[DEBUGGER_ENABLE] is not set to 0 in the application code, when downloading fw to System-RAM via JTAG and disconnecting the debugger, you can replicate this issue. Is my understanding correct?
Yes, but i mean when the disconnection comes from the flashing software, to be more precise :
- CTRL_SYS_REG[DEBUGGER_ENABLE] not set to 0 and "close debug session" option checked in Smart Snippets Toolbox ==> bug replicated
- CTRL_SYS_REG[DEBUGGER_ENABLE] not set to 0 and "close debug session" option unchecked in Smart Snippets Toolbox ==> good behavior
- CTRL_SYS_REG[DEBUGGER_ENABLE] set to 0 ==> good behavior regardless of the "close debug session" state.
Physically unplugging the JTAG doesn't affect the behavior in any cases.
>>>If the CTRL_SYS_REG[DEBUGGER_ENABLE] is set to 0 and the debugger is disconnected, can you replicate this?
No
>>>Question : if you disable the debugger in the application code and boot from SPI Flash, can you reproduce this behavior?
I don't have a flash memory in my setup
Edit :
Just one precision : whenCTRL_SYS_REG[DEBUGGER_ENABLE] is not set to 0 the led wired on pin 10 is not following the behavior of the other leds and is slightly lighted constantly (to be expected since pin 10 must be set on SWIO in this case)
1 month ago
i managed to make it work in OTP by removing the extended sleep.
1 month ago
Hi There,
Glad that you resolved tit. But this sounds like something was not retained during the extended sleep mode..
Thanks, PM_Dialog
3 weeks ago
Hello there,
I have a similar problem, but as for me, I have my code is in the SPI Flash of the dev pro kit.
When I run my code without debugger, I only get the first advertisement, and then it stops advertising, while other tasks run correctly (wakeup from external GPIO, I2C communication). Note that I am using extended sleep mode just like the other customer.
Could you clarify the expected difference in behaviour between running with and without debugger ?Among other things could variables that are not declared in saved RAM be saved in debugger mode ?
Thanks
2 weeks ago
Hi aprocha46,
Thanks for your comment here. Will follow up on this forum thread://www.xmece.com/products/bluetooth-low-energy?post_id=11798#tab-support_tab_content
Thanks, PM_Dialog
1 month ago
Hi There,
Thanks for coming and posting on our forums.
When the device is booting from System-Ram, you mentioned that the application code is working perfectly. Did you test it with or without the debugger attached?
>>>I have been able to reproduce this exact behavior while flashing in sysRam by "forgetting" to set CTRL_SYS_REG[DEBUGGER_ENABLE] to 0 and disconnecting the jtag through the flashing software.
So, with statement you mean that if the CTRL_SYS_REG[DEBUGGER_ENABLE] is not set to 0 in the application code, when downloading fw to System-RAM via JTAG and disconnecting the debugger, you can replicate this issue. Is my understanding correct?
If the CTRL_SYS_REG[DEBUGGER_ENABLE] is set to 0 and the debugger is disconnected, can you replicate this?
>>>Note that it only reproduce the behavior if the jtag is disconnected via a software mean (close debug option when flashing). If i unplug the jtag while it's connection is up, everything works fine.
Do you mean that you can replicate this when the device is booting from System-RAM and the debugger is disconnected?
Question : if you disable the debugger in the application code and boot from SPI Flash, can you reproduce this behavior?
Thanks, PM_Dialog