I have a fresh S32K388 which I'm trying to flash with some from-scratch firmware (this is not AUTOSAR nor RTD). I have the IVT setup to only boot core0, and I have hse_fw_header_start_address just set to zero.
It appears though that this configuration is leading to resets with the MC_RGM DES reporting:
0x00000041 and the MC_RGM FES reporting 0x00010000 which, based on my reading on the S32K3XXRM, implies that HSE watchdog timeouts are leading to a destructive reset based on escalation.
The interesting thing is that this behavior seems to go away when I connect with a j-link, but I can't seem to find a way to disable or service the SWT from my firmware. Do I need to download/install the standard HSE FW for the S32K388?
Is there a reason this is required on the S32K388 and not on the S32K344?
With some further testing - if I clear all the flags in MC_RGM FES/DES after reading them (so they're not sticky across boots), the boot loop starts to return: FES: 0x00010000 and occasionally DES: 0x00000040 (but most of the time DES: 0x00000000)
And for clarity for the original post, I have the boot configuration word in the IVT set to 0x00000001 - which would seem to imply, in my reading, that only CM7_0_ENABLE is set and there shouldn't be any HSE/SWT_0 setting at all?
Based on this post: https://community.nxp.com/t5/S32K/What-does-it-mean-HSE-SWT-RST-on-S32K311/m-p/1955147
And this image of S32K3xx_DCF_clients.xlxs from an older version of the S32K3XXRM: https://community.nxp.com/t5/S32K/S32K388-HSE-No-Response-Error/m-p/2090937/highlight/true?lightbox-...
It appears I may have solved my problem by writing: 0x40000101 0x00100006 to 0x1B000770in the UTEST memory sector (putting "2" into HSE_CLK_MODE_AND_GSKT_CTRL).
In the current revision of S32K3xx_DCF_clients.xlxs, the description of HSE_CLK_MODE_AND_GSKT_CTRL is as follows:
But in the S32K3XXRM, I can't find a reference to what I should be configuring in the gasket configuration (the closest looks like "HSE_B" but the table refers to an impossible 1:1 configuration):
Is this just a documentation update failure? Should I have a 1:4 ratio in HSE_CLK_MODE_AND_GSKT_CTRL if I'm using Option A++ clocking (CORE_CLK at 160MHz, AIPS_SLOW_CLK at 40MHz)?
And just in case my other comment turns out to not be the solution:
- The chip I am using is labelled S32K388HHMJBS 0P39J CTAJ2507E - let me know if you need me to read some registers for specific chip information
- HSE Firmware has never been installed - this is a factory-fresh device which I have only flashed with my bare-metal code
- For the IVT:
- hseFwHeaderStartAddr is zero
- recovery_app_start_address is zero
- I am uncertain which fields to provide from the IVT but everything is basically zero except the header set to 0x5AA55AA5, the boot_config set to 1, and the cm7_0_start_address set to the interrupt vector table
- I already provided the DES and FES I was getting in the original post, but let me know if those were unclear
- I will try and get this uploaded - I need to get approval to post this code publicly
As a quick correction - I meant to write "HSE_CLK at 160MHz and AIPS_SLOW_CLK at 40MHz" for that last sentence in the above comment.
Could you please provide:
The exact S32K388 part number and chip revision being used.
Confirmation whether HSE firmware has ever been installed on the device (or whether this is a completely blank/factory-fresh device).
The IVT configuration, especially the values of hseFwHeaderStartAddr, appBootAddr, and any other HSE-related IVT fields.
The complete reset status register dump after the reset (MC_RGM_DES, MC_RGM_FES, and any other relevant reset registers).
Whether the issue occurs on multiple devices or only on a single board.
A minimal project/application that reproduces the issue, or at least the startup code sequence executed before the reset occurs.
At the moment it is not clear whether the reset is caused by HSE/SBAF, an application issue, or a device configuration issue, so the above information will help identify the root cause.
As far as we can tell - this has solved the issue. I would like to see the documentation updated to reflect that Option A++ requires this gasket change @davidtosenovjan