Two boards STM32H757I-EVAL seem dead after USART1 (CN2) to RS232 connection

[LeonidP]

Hello

 

I got two boards dead within one day. I used the first board for a while and it worked until I started to communicate via USART/RS232. After I faced with such a problem, I replaced the board with a second one and immediately got same result.

Description:

The eval board was powered via STLINK-V3E USB (CN23). JP10 in corresponding position, no other jumpers are reconfigured. No connection to RS232 at the beginning. LCD display showed a nice picture, IDE successfully uploaded and debugged both M4 and M7 etc.

Power off and on at least with the first board did not change the situation as well.

Then I connected it to a PC com port (USART1 via CN2). To do that I used a USB to COM convertor from StarTech.

At the beginning of debugging I got in a PC terminal:

"STM32H747I-EVAL: STFirmware (Fractal) V1.0.0 (Build Feb 8 2019 at 19:22:02)
CPU running at 237MHz, Peripherals at 118MHz/118MHz"

and then my own prints and readings.

Then the story with two boards a bit differs. For example, with the second board I very quickly (in couple of minutes) faced with USART malfunction. It became unable to transmit. Or transmitted just couple of chars I wanted and got stuck.

Anyway, once I turned the board off and then turned on again - no LCD picture and no ability to upload and debug the executables. With the second board and with the first. Both today.

"Target no device found

 

Error in initializing ST-LINK device.

Reason: No device found on target."

"Error in final launch sequence:

 

Failed to start GDB server

Failed to start GDB server

Error in initializing ST-LINK device.

Reason: (4) No device found on target."

 

That happened with two boards in turn.

Besides, I tried to use STM32CubeProgrammer utility. It says that on-board ST-Link programmer is not able to detect the target MCU.

 

Your comments?

[Pavel A.]

If you use the LCD, please connect the external power supply. The USB power from the ST-LINK USB is not enough.

Check the jumpers. Someone could tamper with the board before you.

 

[Chris21]

If your USB to COM convertor from StarTech is RS-232, you cannot connect that directly to USART pins...

[Tesla DeLorean]

CN2 is a DB9 RS232 port on EVAL board, top center-left

https://www.st.com/en/evaluation-tools/stm32h757i-eval.html

 

I don't see this electrically damaging the board unless something is very wrong with the PSU and grounding situation.

The claim here is the STM32H757 is damaged.

The STM32H7's can be come difficult to communicate with and debug if the LDO/SMPS configurations don't match the hardware.

There's a power-cycling, BOOT0=HIGH method to recover those.

As Pavel points out the board really needs to run from the DC supply, the one provided in the box..

More probably a power / regulator issue than one of RS232 per se..

[LeonidP]

Unfortunately no suggestion helps.

 

I dismounted the display. No effect.

I switched power supply to 5 VDC power jack (PCU to CN10) with corresponding JP10 reconfiguration. No effect.

 

All results are identical on both boards.

 

Besides. I measured currency and voltage in test all test points I found. For both boards and both powering I also got identical results, as follows:

Currency on JP9 (with removed shunt) - 1 .. 2 mA (0.001 .. 0.002 A).

5 V (TP5) - perfect

3.3 V (TP7) - perfect

2.9 V (TP8) - perfect

1.8 V (TP12) - perfect

A also measured my USB to COM and got +/-9 V.

 

In both cases USB (CN23) is good. IDE succeeded to upload an upgrade for some peripheral before to unsuccessfully attempt to upload my executables.

 

And let me emphasize one time more that both boards actually worked well (but USART) until I switched them off and then on. At this, USART already got inapplicable. 

 

[AScha.3]

Hi,

something like this :

ed: this is wrong. The CN2 is real RS232 connector, so i was wrong.

IF yes - you killed the cpu's.

Because this is real RS232 with RS232 level output (+/- 8 V or so) , but cpu is 3v3 system and needs a RS232 signal - but at 3v3 voltage level !

So replace the damaged cpu's , or buy new board. Then use for USB - Serial converter something like this :

USB -> serial (3.3 V level)

https://de.aliexpress.com/item/32696427768.html

 

[Pavel A.]

>IF yes - you killed the cpu's.

No. The H7 Eval boards have a normal DB9 RS232 connector.

 

[AScha.3]

@Pavel A.  , your right. I just was thinking, he connect to a cpu uart ...

but CN2 is :

But then : what he did wrong ?

[LeonidP]

Tesla DeLorean,

Thanks a lot! Yes, switching of a SW1 to the position 1 (BOOT0) followed by the flash erasure indeed solves the problem on both boards, but not completely.

I indeed became able to upload new executables and debug them.

But there are still at least the following bad things:

1) I fail at the beginning of the main() of M7-core when the following code is executed:

timeout = 0xFFFF;

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D2CKRDY) != RESET) && (timeout-- > 0));

if ( timeout < 0 )

{

Error_Handler();

}

So, I get into the Error_Handler()

It happens every time. Debugging of the M4 (another main()) does not show a wrong behavior. All initializations seem to be executed perfect.

2) Even without COM port I after a while again became unable to work with the same symptoms as earlier. I.e. I have to erase flash again.

 

 

[LeonidP]

Note that I had no such problem in main() earlier. Before I had to erase flash.

[LeonidP]

Let me add some details to what I found.

 

Once I erase the flash and switch SW1 back to default state (state 0), the code of M4 is loaded to flash somewhere in high addresses. The first non-FF byte address is 0x080FE407. 

 

M4 main () actually has nothing, but HAL_Init().

If I use "step into/over" menu, I succeed to go into HAL_Init() and see, that SYSCLK source is read wrongly. The programs sees HSI, whereas it should be configured as HSE.

If I don't use she step debugging, the behavior can differ, but the main point is that at some time the binary image is copied from 0x080FE407 to 0x08000000. And after that I get back to the initial state when there is no current on JP9 after power reset. I.e. I should erase the flash again.

But even without power reset the debugger eventually loses ability to work with the board (especially if I want to reload), enforcing me to erase the flash and so on.

 

What's wrong?

 

 

[AScha.3]

Did you set the correct power mode , according to the settings on your board ?

(smps mode, i suppose)

see circuit:

 

[LeonidP]

Could be that I recovered somehow.

 

Key steps:

1.Yes, I need to use the external power supply (5 VDC)

2. In project properties, run/debug settings .... GDB connection settings, frequency of ST-LINK debug probe to be set to, say, 1000 kHz instead of "auto".

3. I found a project from examples folder to be uploaded right after flash erasure. Perhaps I might have done an empty project myself. Perhaps. But a project that is generated by IDE as a default one is definitely not good to be used for board (re)initialization. So, there need a project to be used for first uploading.

4. In SW1 = 0 mode both cores (M4 and M7) have to be uploaded at least once, so that flash comprises both images. Only after that the main func of M7 starts properly, as it waits for some actions of M4 at the beginning. 

Not sure, I can say: "all right", but at least I moved on.

 

[LeonidP]

A small question.

I see in my project (in ioc-file): RCC.SupplySource=PWR_LDO_SUPPLY, whereas it should be PWR_DIRECT_SMPS_SUPPLY. If I create a new project for the same board, the value PWR_DIRECT_SMPS_SUPPLY is by default. But in the working project I have no chance to select it, as it's absent in the menu. How to fix?

 

[AScha.3]

>PWR_DIRECT_SMPS_SUPPLY is by default. But in the working project I have no chance to select it, as it's absent in the menu.

The DIRECT_SMPS should be there, maybe try : set chip revision V , set voltage scale 1 . (Just try...never seen this problem.)

+

Is this "working project"  so big ? If not, start new project (from correct board definition) and then just copy your user code parts from "working project" to the new main.c .