S32K358 BMU: FS2633 watchdog reset loop (D26 blinking) after switching from Debug to Normal mode

[samansaki]

Hi NxP Support Team,

I am working with the RDBESSK358BMU board using S32K358 and FS2633.

Based on your guidance in the NXP community, I used the official example:
k358bmu_read_s32ct (MBDT for BMS 1.1.0)

Procedure I followed:

1. Entered SBC Debug mode using SW2
2. Downloaded the example firmware via JTAG
3. Powered OFF the board
4. Set SW2 to OFF
5. Powered ON the board again (normal mode attempt)

Observed behavior:

* LED D26 is blinking continuously
* The system appears to be in a watchdog reset loop
* The transition to normal mode does not occur

My understanding:
According to UM12196, blinking D26 indicates that the SBC watchdog is not properly refreshed and the MCU is being reset repeatedly.

Questions:

1. Does the k358bmu_read_s32ct example include proper FS26 watchdog refresh after exiting debug mode?
2. Is there any required additional initialization sequence for FS2633 before normal operation?
3. Do we need to explicitly handle FS_STATES or watchdog servicing in application code?
4. Is there any known issue when switching from Debug mode to Normal mode with this example?

5. Does it relate to RTD?

Any guidance on how to correctly transition to normal mode would be highly appreciated.

Thank you.
Saman

[mariuslucianand]

Hello @samansaki,

Thank you for posting your question on the MBDT Community!

Before answering your questions, I must notice that there are some misalignments in your setup. First of all, the latest release we have for the MBDT for BMS is the MBDT for BMS, version 1.2.0, so I assume that you are one version behind. Secondly, you are using the RDBESSK358BMU  evaluation board, while the example you are trying to flash is the k358bmu_read_s32ct which targets the RD-K358BMU which is a different setup, and the BMS readings on your BESS board unfortunately will not work because the setup is different.

The example you have k358bmu_read_s32ct id not interacting at all with the SBC, it uses the Switch on the board to set the SBC in the debug mode, and the example focuses on the BMS readings. The example we have in our toolbox which interacts with the SBC is the rd33772c14vevm_s32ct but of course it has a different configuration. This example uses the S32Configuration Tools to configure the SPI pins for the MCU communication with the SBC, also adds the RTD component for the SBC and lastly, It introduces custom code to initialize the SBC. So if you want to configure the SBC on your board, you have to migrate the pins configurations, SPI configuration and also to add the SBC component to the model.

Here are the answers for your questions:

1. Does the k358bmu_read_s32ct example include proper FS26 watchdog refresh after exiting debug mode?

Unfortunately not, the example is configured to work on the RD-K358BMU and not for the BESS board you have

2. Is there any required additional initialization sequence for FS2633 before normal operation?

Yes, the custom code for initialization is added in the InitSbc subsystem from the Initialize under the rd33772c14vevm_s32ct example. Also, you have to configure the SPI pins, and instance, together with the SBC component in the external configuration Toos.

3. Do we need to explicitly handle FS_STATES or watchdog servicing in application code?

Yes, once you initialize the SBC you need to service periodically the SBC by utilizing custom code.

4. Is there any known issue when switching from Debug mode to Normal mode with this example?

No, unfortunately the example targets only the BMS components and not the SBC component.

5. Does it relate to RTD?

Yes, the SBC has its own RTD drivers which are added in the MBDT at least in the MBDT for BMS 1.2.0. But as for all the components we are relying on when generating code, SBC component needs to be configured and initialized in the model.

Hope this helps,

Marius