Hi,
I am working on HSE-B AB Swap on an S32K312 MINI-EVB with HSE firmware version 0.2.55.0 (ab_swap variant). The board is in OEM_PROD lifecycle and Bank A is currently active. Both banks hold the same HSE firmware version.
I have a working reference where a bare-metal main function polls HSE INIT_OK and then submits the activate passive block service. That call returns success and the swap applies on the next reset. Bank B contains a valid IVT with pointers compiled for the lower address space per section 11.3 of RM00286.
The same MU submission code, moved into a bootloader after MCAL clock initialization, returns HSE response 55A5A26A (invalid address). HSE INIT_OK stays set. Other HSE services (AES, RSA, SHA) work correctly in this state. The only difference between the working and failing runs is that the bootloader path writes the MC_CGM MUX 0 divider registers during clock initialization, keeping the source on FIRC but changing the AIPS_SLOW to HSE_CLK ratio from 1:1 (SBAF default) to 1:4.
My main question: what does the invalid address response refer to for the activate passive block service, since the service takes no data structure? Is there a documented sequence for reconfiguring MC_CGM dividers after HSE has reached INIT_OK, that keeps this specific service usable?
I can share the failing binary, register dumps, and clock config on request.
Thanks
Hi David,
Thank you for the guidance about the DCF client. To make sure I set this up correctly on the first attempt, could you please clarify a few things:
1. Point 5 in your list says the MC_CGM MUX 0 source must be PLL_PHI0. Is this a hard requirement — does the activate passive block service require the system clock to be on PLL, or can it also work with the system running on FIRC (48 MHz)?
2. Could you share the earlier points 1 to 4 from the same list? We only have points 5 and 6 in the image and suspect we are missing prerequisites.
3. Point 6 gives the DCF value for a 120 MHz HSE clock scenario. For a 48 MHz FIRC configuration with AIPS slow clock at 12 MHz (1:4 ratio), what value should be programmed into the UTEST_MISC DCF record's clock mode and gasket control bit field?
4. What is the exact UTEST address on S32K312 for this record, and is there a sample or a Design Studio / Cyclone algorithm file we can use to program it safely? Since UTEST is one-time programmable, we want to be certain before writing.
5. Are there any other DCF records required for AB Swap beyond UTEST_MISC — such as an OTA enable marker in UTEST, or OTA indicators inside the active and passive blocks? If yes, please share those as well. Board context: HSE firmware 0.2.55.0 ab_swap variant, OEM_PROD lifecycle, INIT_OK and OEM SU rights bits set.
Thanks a lot,
I guess you don't have setup DCF client what is necessary for use as you described.
1) I didn't want to take a screenshot of point 5, but point 6.
2) It is taken from RM:
3) The key point is ratio 1:4. Also it is described in RM embedded attachment (S32K3xx_DCF_clients.xlsx)
4) DCF record address to be programmed you will have to find out yourself (to find first location with 0xFFFF_FFFF). Specifically is should be around address 0x1B000780, but double check it before programming.
See following document to understand DCF records:
https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC57xx-DCF-records/ta-p/1114884
Also DCF calculator exists:
https://community.nxp.com/t5/S32K-Knowledge-Base/S32K344-DCF-Configurator/ta-p/1986243
I have been using TRACE32 script as follows:
; Program UTEST
do ~~\demo\arm\flash\s32k3.cmm prepareonly
flash.Program 3. /OTP
;put lines generated by S32K344 DCF configurator
data.set 0x1B000780 %QUAD 0x0010000460000101 ;dcf_client_utest_misc
flash.Program off
Mentioned DCF calculator also allows you to create S-records that may be programmed by any programmer/debugger.
5) OTA flag is programmed automatically when AB_SWAP HSE FW is being installed, user don’t need to care of it. I am not aware of other DCF configurations needed.
Hello,
Follow-up: I have prepared the DCF record for dcf_client_utest_misc per your instruction (value 0x0010000460000101, target address 0x1B000768 — first free QUAD on my board, verified). However, S32DS + PEmicro Multilink debug configuration silently skips the UTEST write — bytes at 0x1B000768 remain FFFFFFFFFFFFFFFF after the flash session.
What is the correct tool/procedure to program a single DCF record into UTEST OTP on S32K312 using PEmicro Multilink (or any tool that ships with S32DS 3.6.4)? Do I need a specific flash algorithm file, a different debug configuration, or the standalone S32 Flash Tool?