Dear Everyone,
does anyone know if hardware reset is supported upon connection when isAttach flag is set to true? If so, how can one do it?
We experience strange behaviour on IMXRT1176 EVKB where some interrupts remain active after we reset the board through reset button after attaching to running core.
If there is any other solution to prevent that I would much appreciate if someone could give me some hints.
Best Regards,
Jakub
Hello @jslota13245,
In order to understand and reproduce the issue, could you please provide me the following information?
-What steps are you following when the issue occurs?
-Which interruptions remain active when the reset occurs?
-Are you able to reproduce this behavior with any of our SDK examples? If so, which one?
-What is the purpose of resetting the board while debugging?
BR
Habib
Dear Habib,
thank you for the response.
<-What steps are you following when the issue occurs?
-> I have void LPUART2_IRQHandler(void) defined in my application. I overwrite weak definition from the startup file. I flash the binary with debug symbols, then i attach to running core. For simplicity, let's assume there is a second board connected through LPUART2 which is writing some data to us, let's assume it happens more or less constantly as we can't predict when does it send us something. After attaching we can see kLPUART_RxDataRegFullFlag being triggered. This is expected as we enabled this interrupt.
We use VS-code extension for debugging. It provides us with two buttons for reset. As far as i understand you can reset a debug session and reset a cpu. We use the second. After pressing reset we hit breakpoint at main start as expected. Then i run the core, it reaches LPUART2_IRQHandler with kLPUART_RxDataRegFullFlag before i reach the code which enables this interrupt. This is problematic bit.
<-Which interruptions remain active when the reset occurs?
-> kLPUART_RxDataRegFullFlag
<-Are you able to reproduce this behavior with any of our SDK examples? If so, which one?
-> I haven't tried yet. Though I think it should be reproducible if there is an async uart rx example and you assure that other side of communication is constantly writing UART port. Attaching might be a key clue there, as we don't do 'launch' so maybe hardware is not reset at the start of attach session?
<-What is the purpose of resetting the board while debugging?
-> When i said reset the board, i meant to reset the debugging session or just to jump to start of main. That's how it works while you're in launch configuration at least - it brings you back to start of main so you can debug again without reconnecting. I think it's fairly common operation, though if you see something unusual please let me know.
If i can provide you with any additional info, please let me know
Best Regards,
Jakub
Hello @jslota13245,
I tested this on my side and confirmed that the RDRF (Receive Data Register Full) flag is cleared correctly. To better understand the behavior you are observing, could you please provide the following information?
-When this issue occurs, do you see the RDRF flag being set before the reset is triggered?
When you click Reset and you are stopped at main (before any application code is executed), what is the value of the LPUART2 STAT register?
If you are using the Peripherals view, please click the Refresh button before checking the register values to ensure the displayed information is up to date:
-At the moment the reset occurs, is a UART reception transaction currently in progress?
-Did you make any hardware modification to the board?
-Which version of the MCUxpresso for VS Code extension are you currently using?
-Which version of the SDK are you using?
BR
Habib