STM32L496 USART1 RX crash @ 1.8V IO

[john chen]

Posted on September 12, 2017 at 10:50

Dear community.

I have a very interesting issue - I am working on STM32L496 Nucleo board and working with USART1.  Everything works fine there with USART1 receive/transmitting in INT mode.  (Nucleo runs 3.3v with internal oscillator)

So, I then go make my own board, except that it runs in 1.8v instead of 3.3v.  I verified that my peripheral that I am talking to is also 1.8V IO, and I run the identical build on my own board.

For whatever reason, the STM32L496 crashes on USART1 receive.  I can send as much data as I want to, but whenever I tried to read anything back then system crashes (blinking LED GPIO is no longer blinking on my own board in another thread).

Also verified on the scope that the signals are indeed 1.8v, 9600 baud looks OK too.

BTW, I am running FreeRTOS, ARM GCC compile with Makefile.  I've read as much info as I can in setting up USART1 and things all look ok....  

Feeling is something going on with USART1 RX ISR?  not too sure.  but everything works great on the Nucleo.  I am out of ideas.

Anyone has anything for me to try?  *sigh*

[john chen]

Posted on September 12, 2017 at 10:52

btw, sorry, I meant STM32L496, not STM32L492...

[Tesla DeLorean]

Posted on September 12, 2017 at 11:03

>>

I tried to read anything back then system crashes (blinking LED GPIO is no longer blinking on my own board in another thread).

In these cases you dig out the debugger and understand where the processor is, if it has Hard Faulted, trace that back to see why.

Check the speed and flash wait states are appropriate for 1.8V operation.

[john chen]

Posted on September 13, 2017 at 00:46

Thanks

Turvey.Clive

‌. I dug out the debugger, and it did hardfault, seems like its getting an error on the UART RX, and we're not able to handle the error properly..

Whats weird it why its getting an error. On the Nucleo, there are no errors at all even though we have jumper wires all over the place....

The code seems to be running ok out of flash and SDRAM, so I am assuming that the clock settings are all OK... Its so weird...

[john chen]

Posted on September 13, 2017 at 00:47

Oh one more data point to complicate the weirdness - uart4 is working ok, both TX and RX, but USART3, USART1, and LPUART1 are all crashing.  we are using all the uarts in Asynchronous mode.

Any other ideas would be appreciated...

[Tesla DeLorean]

Posted on September 13, 2017 at 01:13

'Crashing' is so non-specific, what is aggravating the processor? What speed are you running the CPU/buses? What wait state and prefetch settings are being used? What instructions is the processor faulting on, what's in the registers?

>>so I am assuming that the clock settings are all OK

Yes, assuming things gets you into trouble, know if they are correct. Doesn't the FLASH explicitly need more wait states, and the processor have constrained speeds as the voltage drops? Can you see a VDD12 pin, what's the voltage?

Here's an example handler that dumps registers.

https://community.st.com/0D50X00009XkfOXSAZ

[john chen]

Posted on September 13, 2017 at 07:00

OK, I think I found the solution to what is going on.  I'm trying to add another layer on top of the HAL operations to handle errors, and that is causing a crash.  So I removed that and now it doesn't crash.

Another thing I realized is that when the peripheral is powering up, there is no guarantee what it will do on the UART RX line.  This ends up putting unwanted signals on the UART lines, causing the STM32L496's UART port to flag errors.  For now, if I call HAL_UART_Init() AFTER my peripheral powers up, then all is well.   

Now I am going to work on the UART error handler.  Thank you @Clive for the register dump help.  

🙂