S32G399A Custom Board Bricked After Blowing BOOT_CFG1 and FUSE_SEL

[wael_b]

Hello,

I have a custom S32G399A board with QSPI NOR flash (standard connection, similar to RDB3 schematic).

I wanted to force boot from QSPI NOR, so I adapted the Ocotp_Ip_Example_S32G399A_M7 (from RTD) to blow boot fuses, following the suggested values in the Excel sheet attached to AN13456 (S32G3 Boot Process) for QSPI_BOOT_CFG on EVB and the fuse map from the reference manual. The code snippet and my referenced documents are attached to this post!

I verified success immediately after each write in BOOT_CFG using Ocotp_Ip_ReadEFuse() and values were correctly updated (0x2000000C and 0x00000010).

However, now:

• Board is not booting from NOR.
• Serial download mode no longer responds ("Failure to establish communication with target device" on S32 Flash Tool).
• JTAG debugger (PE Micro) reports "the GDB server was not able to establish a connection to the target processor".
  
  

Can you please help finding the root cause? 

[alejandro_e]

Hello @wael_b,

Thanks for reaching out to us and thanks for the very detailed description of your problem. For what I can see you intended to configure the following:

in BOOT_CFG1:

And in BOOT_CGF2, the FUSE_SEL bit, so that the RCON values are taken from the fuses and not from Serial/Parallel values from outside the chip. Please let me know if I understood your configuration correctly.

When you are trying to connect in serial mode (for both flashing and debugging) are you using this configuration? Please note that the values for BOOT_MOD1 and BOOT_MOD2 have different effect as opposed to the case when using FUSE_SEL is 0.

Please let me know the values for BOOT_MOD 1 and 2 you are using.

Thanks

[wael_b]

hello thanks for your reply! 
I confirm that I used the correct BootMod with FUSE_SEL = 1!

After an inspection, we found that the bit 15 of BOOT_CFG1 (which is a "don't care" field in the boot excel) is configuring the XOSC mode (which after fuse configuration we lost the XOSC clock signal on both XTAL and EXTAL pins of the MCU)
So, in our current fuse configuration since bit 15 is zero we are in XOSC differential Bypass mode which is apparently not supported (check the attached screenshots) 
Do you confirm that the Bit 15 shouldn't be zero in our case? 

Please support us to do a second configuration since we still have one working board not configured with the fuses!
Thanks.

[alejandro_e]

Hello @wael_b,

The problem is that the configurations showed in S32G_Bootconfigwords_EVB.xlsx are meant for the EVB/RDB boards, moreover, its meant to be configured in the RCON bits, which are reconfigurable. As you can see at the bottom of the excel sheet, for the don't care bits its better to check the reference manual:

For example, if you check the SD_BOOT_CFG, you will see a lot of "don't care" bits, but the "lack of effect" is for the SD configuration in EVB/RDB boards in particular, it is not that the bits themselves don't have any effect.

Regarding the not supported configuration mentioned in the AN13456, I will need to check internally for more details.

For reference I found the following in an internal document:

"

The bit XOSC BYPASS MODE of BOOT_CFG1 is used to select the external clock source mode for FXOSC module. The FXOSC module can choose one of the three clock source modes as its input. The three clock source modes are respectively Crystal (component) mode, (external) Differential (clock source input) mode and (external single-ended clock source) BYPASS mode. When customers utilizes the passive crystal (which works in Crystal Mode) or active differential clock oscillator (which works in Differential mode) as FXOSC input, they should set XOSC BYPASS MODE 0. In this case, if without other further settings, FXOSC will consider the input working in Crystal mode by default.

Otherwise, if customers utilizes a single-ended digital clock source (which works in BYPASS mode) as FXOSC input, they should set XOSC BYPASS MODE 1.

"

Therefore,  the value of BOOT_CFG1:15 will depend on how you design is configured. For example using 0 requires an external oscillator as in the RDB3 board:

For the board in which you have not blown the fuses of the S32G3, I would recommend using RCON boot to test the configuration that works for your design, as you can see from the fuse map table, the exact configuration will depend on the kind of QSPI memory and how is the oscillator configured. 

Let me know if you need more support.

[haythemLtifi]

hello alejandro_e

I am working on the same board with @wael_b, is the excel file its stated : 

XOSC BYPASS MODE SELECTION : Selects XOSC Mode if XOSC Configuration Fuse is not Blown.
0- Differential
1 - Crystal or single bypass mode

so when BOOT_CFG[15] =0 its in  Differential mode ,

but if its =1 then it either  Crystal or single bypass mode

can i know what doc it stated that BOOT_CFG[15] =0 will work just fine with the crystal ?

in out board we have the same crystal as the EVK , after setting BOOT_CFG[15] =0 the clock source is gone , so i belive the MCU is waiting for this Differential mode crystal and not driving the passive crystal . correct me if i am wrong.

also using RCON is not possible , we can only boot it from fuses . so i hope you can propose to us how to boot our board (which is bases on the evk same flash same crystal ) using the fuses.

[alejandro_e]

Hello @haythemLtifi and @wael_b,

Sorry for the late reply, I have finally recieved information from the internal team, they shared the following:

"

Differential mode is not supported on S32G3. We recommend customers use Crystal mode.
There are two ways to configure Crystal mode:

1. When XOSC configuration is not valid, set XOSC BYPASS MODE SELECTION to 1 – Crystal mode.
2. When XOSC configuration is valid, set XOSC MODE to 11 – Crystal mode.

We recommend using the second configuration, as it provides greater stability.

" 

The validity of the XOSC configuration is given by BOOT_CFG2[0].

I still need to confirm if your board can be recovered or not.

[wael_b]

Hello @alejandro_e ,
Thank you for your support! With your suggested configuration we two cases:

• Case 1:  
  BOOT_CFG1 -> 0x2000800C:
  Bit 29, 15, 3, 2 = 1 and the rest is zeros.
  BOOT_CFG2 -> 0x17:
  Bit 4, 2, 1, 0 = 1 and the rest is zeros. 
  In this, case the JTAG is working (with the recommended serial configuration with FUSE_SEL = 1) but when we try to upload target and algorithm to hardware in S32FT we got an error:
  "Error: Failure to establish communication with target device."
  Also, the XTAL is not showing any signal!
  Could this behavior be related to "XOSC_GM_SEL : GM Sel value for relevent XOSC Mode" Bits 8 to 11 in BOOT_CFG2?
  
  
• Case 2:
  we did the configuration on a second board with BOOT_CFG1 -> 0x2000800C
  And BOOT_CFG2 -> 0x0F:
  Bit 0,1,2,3 = 1
  Do you think this case is recoverable since we didn't blow FUSE_SEL fuse?

[alejandro_e]

Hello @wael_b,

Please find my answers below:

• For case 1. For crystal mode you should configure the GM_SEL according to this formula:
  • ,
    • where:
      • gm: minimal transconductance value
      • ESR: Equivalent series resistance
      • f: Crystal frequency
      • C0: Parasitic capacitance of the crystal
      • C1: Rated load capacitance of the crystal
  • You can also check below table 26 in the S32G3 datasheet Rev4 for some examples:
    • 
  • I also checked the configuration in the examples projects we offer. On those, we use 1100b - 0.631×.
  • Given that the transconductance is a type of amplification of the clock signal, it would make sense that using 0 causes the the chip to not work. I have not tested this myself, so please let me know if changing the value of GM_SEL has any effect on your setup.
•  For case 2. My understanding is that this will depend on the value of BOOT_CFG_LOCK, as shown in the MISC sheet of the fuse map:
  • 
• In theory you should be able to overwrite the values if the lock bits are 00 or 01. However I have not tested this myself and therefore I do not have the full knowledge of the effects.

For case 1, you mention that booting from serial works, I assume in that setup the FXOSC does have an output signal, is that correct?

For the QSPI boot, in your application, are you using RTDs? or are you using an entirely custom software?

Thanks

[haythemLtifi]

Hello , 

Apparently we have 7 hours difference , so i would like to ask you some questions and wael will replay to the rest of your questions tomorrow :

- the gm value in the code you mentioned the 0b1100 , how can i change it? Is it in the clock init fonction?

Or i can change it using the graphic interface? I want to set it to 0b1111 , how to do it?

Right now when i mesure the crystal on the EXtal pin i see an almost dc volatge of value around 800mv , not sure if the crystal is not working properly or because i am not using an active prob , can you please mesure the wave form using a normal prob on the EVK and tell me what you see after you power on the board ? And when you run a code. 

For the board that work in serial , when we select serial using boot mode 0 and 1 we see that the Extal has 800 mv alsmot dc volatage ( its not realy a signe wave but it oscillate ) 

[alejandro_e]

Hello @haythemLtifi,

You can modify the value using the Clock view in S32DS:

Once updating the code the change should take effect in the following file:

This changes take effect when running Clock_Ip_Init() with the structure as a parameter, as described in SW Enablement Guide. 

Let me know if this helps

[alejandro_e]

Hello again @haythemLtifi,

Regarding the test, I can do it, but not at the moment, I will do it next week.

I will let you know what I see from the oscillator.

Thanks 

[wael_b]

You can check the screenshot here from the reference manual talking about the GM_SEL! 

[wael_b]

Hello @alejandro_e,
Replying to this question: "For the QSPI boot, in your application, are you using RTDs? or are you using an entirely custom software?" => Yes, I am using an RTD example not a custom software. 

I have some questions!
- Can you please help me understand this section from the boot process document? (see the screenshot attached)
- Also, is there a dedicated .bin to be downloaded to the Nor Flash or the SD card boot? 
- My generated Siul_Dio_ToggleLed application from IVT is size 5.3Mb, is this a problem?

[alejandro_e]

Hello @wael_b,

Thanks for the information and sorry for the late reply. Regarding the clock test, I will do it as soon as possible and share the results, sorry for the delay.

About your last questions, there is no dedicated binary to download to into the Flash or SD card, just keep in mind that for the Flash you need to program the IVT bin in 0x0000 while for the SD card, you need to program it in 0x1000. 

Regarding the size of the binary, I just did a quick IVT bin with the dio example for the S32G3, it is 5.3M, the size should not be a problem.

Maybe I am not understanding your questions correctly, if I did not answer them please let me know.

One thing you can do to test if the binary is being loaded correctly and its being parsed by the bootROM, is to add a DCD that turns ON the led in your board, for an example, please check the S32G3 HSE DEMO APP, any version should work, for example in version 0.2.51.0, you can check section Appendix 11. S32 DS – Generate a DCD image for powering on the VDD_EFUSE and system RAM initialization, for your problem, the relevant part is the VDD_EFUSE steps. In case you are not familiarized, the DCD is a set of very simple register instructions you can add before your program starts to execute, therefore, it you see the led turning ON in your board after adding the DCD, you can be sure your binary is being loaded correctly and its being parsed by the BootROM.

[haythemLtifi · Accepted solution]

hello , 

we figured the issue with the NOR , the default BootROM clock is 30Mhz , it was not enough to be download the ram of the S32G339A before the time out (500ms) , we out the option to add QSPI config to boost the BootROM clock to 200Mh and that solved out issue.

thanks for your support.

[alejandro_e]

Hello @haythemLtifi,

Thanks for the information. Just to be clear, you don't need any more support from my side regarding this topic correct?

[haythemLtifi]

hello ,
Yes we are good thank you

[alejandro_e]

Hello @haythemLtifi,

Perfect, thanks for letting me know.

If you encounter any problem in the future please create a new post and we will be happy to help you.

Best regards