Replies: 1 comment
-
It's not really a strange behavior since the peripheral seems to be set up at boot time. Anyways setting the peripheral to reset state using hardware dependent functions worked perfectly fine. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am a student working on a project for university "forced" to do something unconventional:
I am currently writing a "custom first stage bootloader/updater" for a nrf54l15. This application is basically just reading a binary over a uart interface which uses the uart async api, writes the data to the memory and then juming to the entry point of the new application. To use the UART ASYNC API I have to set the Kconfig option
CONFIG_UART_ASYNC_API=y
I tried several routines to jump to the new application but the following works:
Now here is the strange thing: after jumping to the reset handler of the new application the code is being executed at first but after executing
uarte_nrfx_isr_int
somehow ends up in an endless loop jumping between_isr_wrapper
andz_arm_exc_exit
Hovever: this behavior doesn't show up when the Kconfig option
CONFIG_UART_ASYNC_API=n
is disabled.My question is now Why does the secondary application doesn't boot up correctly when the Kconfig option is set?
My guess is that the DMA which is used for the uart async api (or the uart interrupts) probably causes these problems. However i didn't find a way to reset the peripherial to a state in which the problem doesn't occurs anymore.
This is actually not the first time facing problems with this API (my application ran into a hard fault when set up the callback for the API and simultaneously used spawning threads)
Beta Was this translation helpful? Give feedback.
All reactions