S32 flash tools upload eMMC or QSPI algorithm to S32G3 failed

[XD]

Hi,

We built a few customized S32G3 boards. On two of these boards, when I tried to flash eMMC, I saw that the algorithm was loaded, but at the end, I got an 'Algorithm initialization is failed' error. A screenshot is attached. This eMMC failure occurred on both boards.

I also tried flashing QSPI. One board had the same algorithm initialization failure as eMMC, while the other successfully loaded the algorithm. However, I couldn't retrieve the flash ID or upload a file to the device afterward due to a communication timeout.

The S32G3 chips on these boards should be fine—I was able to use the S32 probe to load an ELF file into memory and run the routine. The rest of the boards have no issues. We checked the hardware and found no visible damage. We also used a Dediprog to program a known working QSPI image onto these two boards, but there was no console output.

Could you please advise what might be causing this issue?

Thanks,

XD

[chenyin_h · Accepted solution]

Hello, @XD 

For the possible reasons of the issues shown from your test, there are some useful information from the "troubleshooting chapter" of S32 flash tool user guide, as attached:

BR

Chenyin

[XD]

Hi @chenyin_h ,

Thank you for the information. It’s very helpful, and I appreciate your support.

Thanks,

XD

[chenyin_h]

Hello, @XD 

Thanks for your reply.

I have checked the error prints of S32 flash tool shown from your logs, but there seems no valid information from the document in hand, I am checking with internal team for further information, I will reply you later if any findings have.

Sorry for your inconvenience.

BR

Chenyin

[chenyin_h]

Hello, @XD 

Thanks for you reply.

I am not able to say that it is impossible for the issue you mentioned, but it is with low possibility that 2 of 7 silicon are damaged from our experience.

Flash tool is not a debugger, would you mind trying flashing the images with Lauterbach?  

Not sure if the UART1 is available on your custom board, if yes, I also suggest building the UART RTD examples with UART1, and then load it to the SRAM via debugger to check if there are any prints or signals from the tx pin.

BR

Chenyin 

[XD]

Hi @chenyin_h ,

Thank you for your reply.

Unfortunately, we don’t have Lauterbach available at the moment. Additionally, we have another external device connected to UART1, so we need to explore alternative ways to capture the output.

We will focus on investigating potential hardware damage. Thank you for your suggestions.

Regarding the S32 Flash Tool, could you provide more details on why it loads the algorithm successfully but fails during initialization? Are there any error codes or logs available? What could potentially cause this issue?

Thanks,

XD

[chenyin_h]

Hi, @XD 

Thanks for your reply.

Likely hardware issue, may I know what is the percentage of devices with issues? since other boards with same design works fine with the flash tools.

Not sure if the two boards could boot from other methods like SD, if yes, may I know if the two boards could be operated correctly with UART, eMMC and QSPI via BSP or RTD?

BR

Chenyin

[XD]

Hi @chenyin_h ,

Two out of seven boards have this issue.

We tried several approaches:

1. Using the S32 Flash Tool to flash eMMC and QSPI failed because the tool reported an initialization failure.
2. Flashing a working image to QSPI using Dediprog and booting from there, but unfortunately, there was no UART output. We measured the TX signal on the S32G UART and found no activity from the chip. Additionally, the power supply current was lower than on working boards, suggesting that the chip might be stuck. However, we could see an echo when typing in Minicom.
3. Loading an ELF file into memory using the S32 probe appeared to work fine—we were able to run example code.

I believe the UART (connector and cable) on the board is functioning correctly. Could this issue be caused by damage to the chip, such as ESD or a soldering defect?

Thanks,

XD

[chenyin_h]

Hello, @XD

Thanks for the post.

Since the issue existed on your custom board, may I know if the eMMC/QSPI models are different from the ones that on RDB3? which version flash tools used?

BR

Chenyin 

[XD]

Hi @chenyin_h ,

Thank you for your reply.

The eMMC and QSPI are exactly the same as on the RDB3, and the flash tool version is 2.1.7. Only these two boards have the issue—all other boards are working fine.

Thanks,

XD