S32 Debugger and board bring up with S32G274

[armandorl]

Hello,

We are having issues on a custom board based on the S32G-VNP-RDB2. We are currently going through the HDG document, to try to identify issues in our design, but we would like to know what are the minimum requirements to use the S32 Debugger. We are trying just to establish communication with the board via the S32 Flash Tool GUI using the Test connection, but we just get:

Checking connection ...

Error: Failure to establish communication with target device.

We tried to connect the oscilloscope to see if there were any signals for example the JTAG TCK but didnt see any signal when pressing the "Test connection". The debugger shows TX/RX in green and the RUN/PAUSE is amber, so it means it detected power, but no signals are detected. We checked the required pull ups and pull downs, we are using a 10-pin connector, and JCOMP is also already pulled up as mentioned in the AN12530.

So questions:

1. Should it be possible to see the JTAG_TCK? at least coming from the S32 Debug Probe?

2. Which boot mode should we set on the BOOTMOD pins? Or is this not relevant when using the debugger?

3. Finally on section 14 of the HDG this is mentioned: During initial power-on while asserting the POR_B reset signal, ensure that crystal or oscillator EXTAL/XTAL is active before releasing POR_B. See the image attached, it seems the EXTAL oscilation(channel 2 green) starts after POR (channel 1 yellow), I checked the VR5510 booting order and the voltages and sequence order seems correct, is this image as expected or really the oscilation should start before the POR?

Hopefully I've provided enough information, else please let me know if you require more details.

Thanks for the support.

[Daniel-Aguirre]

Hi,

On regards of overall bring-up support, we can recommend contacting your local NXP FAE/DFAE/representative, for them to provide the adequate channel.

As for your questions, below will be some comments on them:

1. Should it be possible to see the JTAG_TCK? at least coming from the S32 Debug Probe?

[NXP]: You should be able to, since it is the clock signal going from the probe to the S32G. You should be able to probe directly the connector of the debug probe (without connecting it to the board) to confirm the behavior). Also, we see that under RDB2 board there is no 10-pin JTAG connector for S32G (only 20-pin). We can recommend looking into the EVB3 schematics available under the EVB3 product page (link: S32G Vehicle Network Processing Evaluation Board 3 | NXP Semiconductors), in which a 10-pin JTAG interface is available for S32G processor.

We can recommend to double check the pull-ups and pull-downs with the ones available under the EVB3.

2. Which boot mode should we set on the BOOTMOD pins? Or is this not relevant when using the debugger?

[NXP]: For debugging purposes, BOOTMOD pins should be all 0's.

3. Finally on section 14 of the HDG this is mentioned: During initial power-on while asserting the POR_B reset signal, ensure that crystal or oscillator EXTAL/XTAL is active before releasing POR_B. See the image attached, it seems the EXTAL oscilation(channel 2 green) starts after POR (channel 1 yellow), I checked the VR5510 booting order and the voltages and sequence order seems correct, is this image as expected or really the oscilation should start before the POR?

[NXP]: As told under the HDG, the frequency should already be available prior to deassert the RESET signal. If not done, once S32G is not under RESET there will be no reference clock for it to use, hence it will go into an undefined state. Since when the oscillator starts is not stable (it requires some time to stabilize) then it might enhance the undefined state.

Also, the following recommendation is also available under the S32G2 HDG [Page 50, S32G2 Hardware Design Guidelines, Hardware Design Guidelines, Rev. 8, 06/2022]:

"When checking crystal frequencies, use an active probe to avoid excessive loading. A passive probe may inhibit the crystal oscillator from starting up."

Please, let us know.

[armandorl]

Hi Daniel,

Thanks for your response. I will check the TCK without connecting to the board, and also try with an active probe. I am going through the checklist on the HDG before contacting them. On your suggestion for the 10pin I checked the Evaluation Board 3 schematics and noticed the TDO has a 100k ohm pull up, but the AN12530 says TDO could have No pull up. Is that really required? Also silly question but all the DNPs in the schematics should really not be populated right?

Thanks!

[Daniel-Aguirre]

Hi,

Thanks for your feedback. On regards of the TDO, since it can be taken as a soft pull-up might not be a problem, still we can recommend putting the note of DNP/DEPOP if required.

That is correct, DNP should be a Do Not Populate note. This is at the end a note under the schematic for a specific version of the board. The BOM is the one detailing the specific components that should be poped under the schematic, which should match with those DNP notes under the schematic.

Please, let us know.

[armandorl]

Thanks once again for your response, then all pull ups/downs are OK. As mentioned in my original message I was trying to use the "Test connection" on the S32 Flash Tool GUI, but that was not working. I now tried to use the S32 Design Studio - Debug Configuration - S32 Debugger - Debugger - Test connection. And it seems that from here I do get a successful response. I also see the TX/RX led with activiy quick red flashes. So what is the difference between these 2? Why the first one is not working?

Is it possible to achieve the same functionality of the S32 Flash Tool from the S32 Design Studio debugger? (Select algorithm to flash QSPI?)

Here, the versions of the tools:

S32 Flash Tool
Version: 2.1.7
Build id: 231218

S32 Design Studio for S32 Platform
Version: 3.5
Build id: 231219 (Update 9)

Thanks for all the support so far!

[Daniel-Aguirre · Accepted solution]

Hi,

Thanks for your feedback. Below will be some comments on regards of the following question:

Q1 >> So what is the difference between these 2? Why the first one is not working?

[NXP]: S32 Flash Tool establishes a serial connection with the S32G (UART0), and the test connection verifies the serial interface. S32DS Debugger uses the debug probe itself.

 Q2 >> Is it possible to achieve the same functionality of the S32 Flash Tool from the S32 Design Studio debugger?

[NXP]: It might be possible. Which functionality are you looking for?

Please, let us know.