[S32K144EVB]Board stuck after mass erase.

[alexandrehochar]

Hi,

I have a problem after an unlucky erase block command in my code.
The chip can't be programmed or erased.
Check the emergency option in debug config doesn't work.
I don't know how an erase command can stuck the chip.
Indeed, 0b11 on FSEC->SEC protect the chip but 0b11 on FSEC->MEEN enable the mass erase.

Because mistakes never happen alone, i stuck two boards like this. I need help!

How i can reuse my boards ?

Regards,

[ev1]

Good Evening i'm experiencing the same issue even though the m_flash_config section is present and defined as follows:

 m_flash_config        (RX)  : ORIGIN = 0x00000400, LENGTH = 0x00000010

I would like to know if I can write P-Flash while running code from it (DEBUG_FLASH configuration) if the section to be written was pre-defined to store in the data, in a proper P-flash region in the linker file and is different from the region from which the code is run.

Thank you in advance

[RadekS]

Hi Emanuele,

In general, you cannot read (execute code) from the same flash bank while you are writing it.

The S32K146 and S32K148 derivatives have two/three P-Flash banks. The lower derivatives just one.

The typical solution is that software for P-Flash write must be executed from different memory area e.g. from RAM or D-Flash. During the write command execution, also all potential interrupts must be disabled or potential interrupt routines placed in RAM or D-Flash.

For more details, you may look at https://www.nxp.com/docs/en/application-note/AN12218.pdf
https://www.nxp.com/docs/en/application-note-software/AN12218SW.zip

And https://www.nxp.com/docs/en/application-note/AN12323.pdf

https://www.nxp.com/docs/en/application-note-software/AN12323SW.zip

I hope it helps you.

Best regards

Radek

[RadekS]

Hello Alexandre,

Unfortunately I dont have direct experience with such issue.

Have you read this thread or this document?

Although it is Kinetis, it should be similar.

Best regards

Radek

[alexandrehochar]

Hello Radek,

Thank you for your reply. These documents describe exactly my problem. But i work on S32K with a P&E programmer and the software tools to access directly to the register is too expensive and i don't find if the software works with S32K series.

Regards,
Alexandre

[RadekS]

Hello Alexandre,

Thank you for your note and sorry for my late response.

I discussed it with my colleagues.

1. Could you please describe steps which leads to MCU lock on your side that we can simulate it on our side (testing on board with ZIF socket)? If you used your own software, could you please share it also?

2. If you can connect an MCU, you should be able to load code into RAM. Could you please try to create a project from SDK example “flash_partitioning” (potentially “csec_keyconfig”), built it for RAM target and execute it in MCU?

BTW: Do you use NXP evaluation boards with OpenSDA interface or your own board and PEmicro interface? Which version od S32DS and SDK you use?

I hope it helps you.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[alexandrehochar]

Hi Radek,

I tried to programmatically write in flash section, so i executed these steps:
 - Erase sector.
 - Write each phrase of 8 bytes by a for() loop.

For each command i used this code :

void executeFlashCommand(uint8_t a_cmd, uint32_t a_addr, uint8_t *a_pageBuffer) {
   uint8_t v_AddrVec[3];

   v_AddrVec[0] = (a_addr & 0x00FF0000) >> 16;
   v_AddrVec[1] = (a_addr & 0x0000FF00) >> 8;
   v_AddrVec[2] = (a_addr & 0x000000FF) >> 0;

   INT_SYS_DisableIRQGlobal();

   while ((FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK) == 0);
   FTFC->FSTAT = FTFC_FSTAT_ACCERR_MASK | FTFC_FSTAT_FPVIOL_MASK;

   FTFC->FCCOB[3] = a_cmd; //Program Phrase command (0x07)
   FTFC->FCCOB[2] = v_AddrVec[0]; //Flash address [23:16]
   FTFC->FCCOB[1] = v_AddrVec[1]; //Flash address [15:08]
   FTFC->FCCOB[0] = v_AddrVec[2]; //Flash address [7:0]

   if (a_pageBuffer != NULL) {
      FTFC->FCCOB[7] = a_pageBuffer[0]; //data
      FTFC->FCCOB[6] = a_pageBuffer[1];
      FTFC->FCCOB[5] = a_pageBuffer[2];
      FTFC->FCCOB[4] = a_pageBuffer[3];
      FTFC->FCCOB[11] = a_pageBuffer[4];
      FTFC->FCCOB[10] = a_pageBuffer[5];
      FTFC->FCCOB[9] = a_pageBuffer[6];
      FTFC->FCCOB[8] = a_pageBuffer[7];
   }

   FTFC->FSTAT = FTFC_FSTAT_CCIF_MASK; //launch command
   while ((FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK) == 0); //wait for done

   INT_SYS_EnableIRQGlobal();
}

But by mistackes i sent an erase block (code 0x08) instead of erase sector (code 0x09).
And directly after sending, because the code was erase, the board crash.
And the software S32K cannot access to the chip, even in RAM mode.
(I retried this morning to connect the board and now the software can't access to the debuger).

The debuger used is the openSDA on the S32K144EVB board.

[jiri_kral]

Hi Alexandre, 

i tried your scenario - flash target, use 0x08 command on address 0x000000. As expected - communication between PE Micro and EVB  was stopped. But when I start new debug session - I got this message: 

By clicking on Yes - I can normally upload program into flash and use EVB. It is impossible kill chip by erase only. There must be inside byte on address 0x40C on bits 4-5 10b (Mass erase disabled). This is the only way how to - by secure feature - turn chip into brick. 

You can also check the startup code (Startup_S32K144.S) in Project_Settings/Startup_Code if there is present flash config section with correct SEC byte:

/* Flash Configuration */
.section .FlashConfig, "a"
.long 0xFFFFFFFF /* 8 bytes backdoor comparison key */
.long 0xFFFFFFFF /* */
.long 0xFFFFFFFF /* 4 bytes program flash protection bytes */
.long 0xFFFF7FFE /* FDPROT:FEPROT:FOPT:FSEC(0xFE = unsecured) */

.text

Check also your linker file if contains m_flash_config section on correct address:

 m_flash_config        (RX)  : ORIGIN = 0x00000400, LENGTH = 0x00000010

It may happen that by mistake is text section starting bellow address 0x400 - and in this case you can write some random data (part of program instruction) on address 0x40C containing 10b on bit 4-5. 

Jiri 

[alexandrehochar]

Hi Jiri,

You have exactly the same message then me, when i try to reprogram the board.
But if i click yes , the message comeback and after 2 yes, the debug session close.
I checked .S and .ld and all is correct.

The problem is that the reset pin is always at low level. It raise up during few hundred of microsecond and fall down in loop. In Kenetic chic is due to an hardware protection if the chip is overheating.

Thanks,

[kt1003]

This is exactly the mistake I made: it's not clearly marked with CAUTION!!!!! notes in the reference manual. I made a mistake with the linker file and put program code over 0x400-0x40f and bricked two EVBs. I now generate S-records and check by hand 0x400-0x40f: any kind of mistake or bug in the linker or other tools will likely kill the chip.

I don't really understand why the chip can't have an emergency erase using a special programming pin or special voltage: anyone wishing to hack a device with a blank chip can always solder their own in place. All it does it massively increase the risk of bricking cars on a production line by accident.

[RadekS]

Hi Alexandre,

Thank you for clarification.

We will test it on our board.

There is also quite significant (potential) issue in your code. If your code is built for execution from Flash, you cannot simultaneously read (it means to execute a code) and write/erase the same flash block.

 

So, at least next two lines of C code must be executed from RAM:

   FTFC->FSTAT = FTFC_FSTAT_CCIF_MASK; //launch command
   while ((FTFC->FSTAT & FTFC_FSTAT_CCIF_MASK) == 0); //wait for done‍‍‍‍

From this point of view, it looks like that Erase Flash Block command was interrupted somewhere in the middle of the execution.

Have a great day,
Radek

[alexandrehochar]

Hi Radek,

I have obviously have execute this code in ram section. And with correct erase sector command (code 0x09), the code work perfectly.

Thanks,

[kt1003]

Does this mean that if there's a bus fault on read-while-write (e.g. also running from flash) then the flash block erase could result in indeterminate values and accidentally set the security on and disable mass erase?

[RadekS]

Hi Ken,

Unfortunately, I am not sure what exactly happened.

When you start erase/write command at flash block and you read it simultaneously, you will read incorrect data with high probability. So, the MCU behavior when CPU execute “random” code is quite unpredictable.

I suppose, that soon or later bus fault or MCU reset must happen…

I hope it helps you.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------