Using SDK 5.0.4 on the DA14580. Can't get systick_wait() to work under 15us. Code below toggles the GPIO high for 15us. I've tried using the callback exception (using systick_register_callback() in systick.c) and see the same results. I can set the GPIO to toggle for 20us with systick_wait(7). So it seems there's a minimum systick wait of 15us with systick_wait(2) and adding 5 more microseconds with systick_wait(7) gets to 20us. This is a vanilla SDK 5.0.4 build - no modifications to any code, other than the addition of a user template.
GPIO_SetActive(GPIO_PORT_0, GPIO_PIN_2);
systick_wait(2);
GPIO_SetInactive(GPIO_PORT_0, GPIO_PIN_2);
Thanks for your help,
Alex
Device:
Hi apogostin,
The parameter passed to the systick_wait function has units of micro-seconds. So, could you please make sure that the GPIO is toggling after 20us? Also, could you please clarify what you are trying to accomplish? You would like to toggle the GPIO once or blinking it?
Thanks, PM_Dialog
When systick_wait() is set for 2us the GPIO toggles for 15us. I can confirm I'm looking at the correct pin because when I set systick_wait() to some other value I can see the duration of the toggling change. For example, when setting systick_wait() to 7 I see the GPIO toggle for 20us. I've tested this out several times using an o-scope.
There seems to be a 15us minimal interval when using systick_wait(). I'm triggering the code at millisecond intervals (~8ms). So every ~8ms I should see the GPIO toggle for 2us, but its toggling for 15us.
也许还有其他中断影响当systick_wait() gets serviced? I see a SVC_Handler (ARM SVCall) and PendSV_Handler (ARM PendSV) inside the interrupt vector table. Maybe these handlers are using the 15us?
Thanks for your help,
Alex
Hi apogostin,
Could you please kindly let me know in which project of the SDK are you working on? Do you have BLE activity or you are using any of non-BLE examples of the SDK? The reason I am asking is to try to replicate your issue.
Thanks, PM_DIalog
As I stated in my previous post, I'm using a vanilla SDK 5.0.4 SDK - no modifications other than the addition of a user template. I'm using your documentation (DA1458x Software Developer's Guide UM-B-050, dated 22-Jul-2016) to create the user template. Please see chapter 9 Creating Your BLE Application. I've used these instructions to create the user template.
Again - thanks for your help,
Alex
Hi apogostin,
I tried to replicate your issue and you are right. With the code that you have posted, I got 18.08 uSec delay. The reason for that is because the wait period (2 uSec) is extremely low. You can reduce the waiting period by explicitly writing to the GPIO register and not call the GPIO_SetActive() / GPIO_SetInactive() APIs. With the following code snippet, I reduced the time from 18.08 uSec to 9.083 u Sec:
Thanks, PM_Dialog
感谢确认。我可以看到谷歌价格指数O_SetActive() the use of the DEVELOPMENT_DEBUG macro (set to true with CFG_DEVELOPMENT_DEBUG). It would be interesting to compile and run the code with the DEVELOPMENT_DEBUG macro set to false? Regardless, it still does not explain your missing ~9us - even with the direct set/clear of the GPIO register. But, it is again greatly appriciated that you were able to duplicate this issue, I can now work around it.
Thank you,
Alex
Hi apogostin,
If the CFG_DEVELOPMENT_DEBUG is defined, you will be able to debug your firmware and you can emulate the deep sleep mode without programming the OTP memory. By undefining the CFG_DEVELOPMENT_DEBUG, you disable the debug mode, so you will not able to hot attach debugger and get debug information. For example if a Hardfault or NMI will be occurred, you will not able to catch it.
Thanks, PM_Dialog