stm32H743 and usart2 problem

[Franzi.Edo]

Posted on November 29, 2017 at 17:26

Dear All,

I have just ported the RTOS uKOS (

http://www.ukos.ch

) on the new stm32H743. Everything work fine at the exception of the usart2. I have strange situations with the interruptions, and as soon as I receive a character in the interruption handle, I have a crash machine (hard fault). It is tricky and difficult to figure out what is the real problem. I replaced the usart2 with the 3 with exactly the same initializations and everything work like a charme. I suspect a silicon problem (I use the revision Y) but I didn't find anything concerning this behavior in the errata. Has anyone experienced the same behavior? Any help or suggestion from ST?

Best regards

   Edo

[Tesla DeLorean]

Posted on November 29, 2017 at 17:32

Suggest you work with the FAE supporting your account.

Create a minimal example that illustrates the failure. If you have a silicon bug you should be able to demonstrate and replicate it.

Review carefully the information the Hard Fault exception provides.

[Franzi.Edo]

Posted on November 29, 2017 at 20:25

Hi Clive,

Thank you for the FAE support idea.

I will try to isolate the problem with a minimal set-up (but it will be difficult).

Regards

  Edo

[Joerg Wagner]

Posted on January 19, 2018 at 23:57

Just created a small app with CubeMX (NoSYS) on NUCLEO-H743ZI using UART5 and USART2.

UART5 sends via DMA a string (PB13) and USART2 receives it via DMA or IT on PD6. Speed: 115200

Both works perfect: No hardware issue.

- Joerg -

[Franzi.Edo]

Posted on January 22, 2018 at 14:35

Hi Joerg,

Thank you for having tested. Unfortunately, I continue to suspect a silicon problem. I tested in exactly the same conditions the usart2 on the NUCLEO board successfully. I had the impression to have posted the mail I sent to ST but I just discovered some missing information. So, here is the complete one:

Regards

  Edo

Dear ST team,

I am facing to a problem concerning the usart2 of the new H743. I suspect a silicon bug!

As soon as I stress a bit the communications handled by the usart2 (reception @ 460800-bps) after a while I have an hardfalut exception. It is difficult to give you more information because the stack is also corrupted. 

Now, this happens only with the stm32H743IIK6 (silicon revision 7BA7R VQ). The same software running on other variants of your CPU works perfectly. I successfully tried the usart2 on the Nucleo-144 (stm32H743ZI silicon revision 7B744 VQ).

So, for my design I need the version  stm32H743IIK6. 

Question:

- How you can explain the behavior difference between the 2 chips ?

- Can you confirm that I have a bad silicon ?

- Is this problem known @ ST ?

- Do you have a more recent errata ?

[waclawek.jan]

Posted on January 22, 2018 at 14:48

It is difficult to give you more information because the stack is also corrupted. 

What do you mean by 'stack is corrupted' exactly? Where does the stack pointer point to, and if it's the memory the stack normally sits in, what's its content?

The same software running on other variants of your CPU

Do you mean, the same binary?

JW

[Tesla DeLorean]

Posted on January 22, 2018 at 15:30

Per

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

'

Disable caches or prefetch options. Instrument the snot out of the Hard Fault Handler so the system can decompose the state out the serial port sans debugger.'

You really need to get to why and how the stack gets screwed up. Absent a debugger you're going to need to determine flow and interaction via instrumentation of your code.

Have code that decodes the chip/stepping being used, and the frequency of the core/buses.

Cache coherency can be a big problem. Turn of caches and optimization, have a bit to enable/disable the former in your binary so it can be switchedat runtime.

>>

Do you mean, the same binary?

Jan's point here is that the exact same binary should be able to drop into both boards and demonstrate normal and aberrant behaviour.

The IC design and validation guys need something to work with. They are not guys you want goose chasing software issues, understand 9% of the things people claim are 'silicon defects' are in fact software issues, so you really have to make a rock solid case you've found something.