We've got a device where we want UART1 to be initially disabled, and then selectively enabled and disabled based on another input. Unfortunately, when I attempt to call the UART_PDD_EnableTransmitter() macro the system ends up crashing. Tracking into the assembly, when the final store instruction is called to write the UART1_C2 register the value written is not correct and the other UART registers end up corrupted.
Attached are screen grabs from within IAR showing the CPU registers, UART1 registers, and disassembly just prior and just after the execution of the STRB R3, [R0] instruction.
This is the before image, and R0 points to the UART1_C2 register address and R3 holds the expected 0x08 to set the Transmit Enable bit.
Here is the registers after the next step. All the UART1 registers are now reading 0x20. I also don't understand why my Link Register and Stack Pointer changed as the UART_PDD_EnableTransmitter and UART_PDD_EnableReceiver are Preprocessor macros that are inlined into the ASerialLdd2_Enable() function.
After this, if I attempt to continue to run the system crashes with a "Stopped by a vector catch" issue.
Solved! Go to Solution.
We figured it out: the i.MX on the board we were communicating with was holding the Tx line low when powered off. On boot both chips came up briefly, which allowed the serial line to initialize if we initialized it during the boot process, but if we left it alone the i.MX was shut off and holding the line down. We're guessing that the KL chip detected the error and ended up resetting in an attempt to clear it.
We've added a delay to enabling the serial line after we start the i.MX chip and it has resolved it. We're looking at changing the layout of the next board to prevent this issue.
We figured it out: the i.MX on the board we were communicating with was holding the Tx line low when powered off. On boot both chips came up briefly, which allowed the serial line to initialize if we initialized it during the boot process, but if we left it alone the i.MX was shut off and holding the line down. We're guessing that the KL chip detected the error and ended up resetting in an attempt to clear it.
We've added a delay to enabling the serial line after we start the i.MX chip and it has resolved it. We're looking at changing the layout of the next board to prevent this issue.
Hi Luciano,
I am using KDS3.2.0 with IAR , test the Typical Usage of Serial_LDD on my FRDM-KL25Z board.
The AS1_Enable() run normally.
Would you please attach your project here, so I can test it.
Best Regards,
Robin
I'm not going to attach my proprietary project to a public thread. My FAE is going to be on site today, so I'll grab him and try and work through it.