Thanks for reporting! I was able to reproduce the problem on the older K66FX1M0 Your solution is correct, but...
Please be aware that OpenOCD project requires submitting patches to the Gerrit review system, we are not able to accept patches from mails and tickets. See https://openocd.org/doc/doxygen/html/patchguide.html In this case I made an exception as I want to remove the `assert()` to prevent the MCU locking effect (and I'm the author of this bug ;-) Please test 8719: flash/nor/kinetis: fix assertion during flash write | https://review.openocd.org/c/openocd/+/8719 I added your mail to Suggested-by clause of the commit message. I hope it's enough to express your credit. BTW Don't you want to contribute a S32K1xx part of `kinetis_nvm_partition` handler? You already managed it in python, so it should be easy to rewrite to C... --- **[tickets:#448] Flashing S32K with FlexNVM partitioned as EEPROM crashes OpenOCD & puts chip in secure state** **Status:** new **Milestone:** 0.10.0 **Created:** Fri Jan 17, 2025 03:06 PM UTC by Jasper v. Blanckenburg **Last Updated:** Fri Jan 17, 2025 03:06 PM UTC **Owner:** nobody **Attachments:** - [init-s32k-eee.py](https://sourceforge.net/p/openocd/tickets/448/attachment/init-s32k-eee.py) (6.4 kB; text/x-python) - [kinetis_eeeprom.patch](https://sourceforge.net/p/openocd/tickets/448/attachment/kinetis_eeeprom.patch) (425 Bytes; text/x-patch) I'm working with an S32K116. When I 1. Mass-erase it with `kinetis mdm mass_erase` 2. Partition the FlexNVM as EEPROM (using the attached Python script) 3. Try to flash the MCU (by attaching with GDB and running `load`) OpenOCD crashes with an assertion failure in `src/flash/nor/kinetis.c:1492`. If I restart OpenOCD and try to flash the chip again, I get the message that the MCU is in secured state. As far as I understand, this happens because `kinetis_probe()` detects the EEPROM partitioning and thus does not allocate `sectors` or `prot_blocks` (`kinetis.c:3022`). If I add a check for `num_prot_blocks == 0` before the assert (see the attached patch), OpenOCD no longer crashes and the MCU does not go into secured state. I'm not sure if this is the correct place to fix it --- the assertion is kind of obvious, but I don't understand why the MCU goes into secured state, or why not failing the assertion prevents going into secured state. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
