Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forcing magic_halt during mass-erase of kinetis devices. #7

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

haata
Copy link

@haata haata commented Jun 7, 2015

  • If chip is already flashed, mass erase will not erase unless reset
  • Also works when unlocking a secured chip (just hold down reset when calling mass erase)

Some background:

  • Using a bus pirate for flashing thousands of devices in a factory
  • If the device happens to be flashed with the incorrect bootloader (or flashed multiple times) the procedure changes (more instructions to give), so just forcing an erase/unlock
  • If the chip is actually locked, then have the person flashing hold down the button after the first attempt

(It would be nice to actually control the reset line with the bus pirate, similar to a jlink flasher but I'm not familiar enough with ruby/bus pirate to do that right now)

- If chip is already flashed, mass erase will not erase unless reset
- Also works when unlocking a secured chip (just hold down reset when calling mass erase)
@corecode
Copy link
Member

corecode commented Jun 7, 2015

Thanks for your submission. I've been heavily restructuring the code (see the cmsis-dap branch). I'll try to add the same behavior to the new code.

I believe that I have seen JLink adapters mass-erasing the target without me holding down reset, but they might have just used the reset line.

@haata
Copy link
Author

haata commented Jun 7, 2015

Cool, looking forward to the re-factor.

I had a lot of flashing issues with the mk20dx256vlh7 (had to put series resistors on the SWD CLK and IO lines to get it to work). Caused me to inadvertently secure the chip often. Ended up buying a jlink adapter to attempt to unlock. It requires the Reset pin attached to it.

@corecode
Copy link
Member

corecode commented Jun 7, 2015

Good to know. I've been working on dedicated programming hardware (with SWD series resistors). Maybe I can get you interested in getting some for your next project :)

@haata
Copy link
Author

haata commented Jun 7, 2015

Neat!
Also, I make sure that the CLK and IO trace lengths are matched (just in case).

I've been trying to standardize on the J-Link needle connector (TC2050-IDC) because it'll do both SWD and JTAG if I need it. Unfortunately Segger flashers are too expensive (I have one, but it's not reasonable to expect everyone to have one, or buying a bunch for the factory). For the bus pirate we just have an adapter to break out the SWD, GND and +5 V.

At minimum I just need SWD (and ideally RESET line control)
Another interesting feature the jlink's have is a power level check. Basically, after you tell it to apply 5 V supply, it measures VTref to make sure you're at the correct voltage before attempting anything (i.e. 3.3V). Not really required, but helps debug soldering issues.

(Got 2000+ chips to flash for the Infinity ErgoDox)

haata added 3 commits June 7, 2015 20:01
- Used to do ruby module checking
Will be used to select a specific bootloader to flash based on the MCU detected

- Using --detect2file, read out registers to /tmp/detectlog.log
  * SIM_SOPT1
  * SIM_SDID
  * SIM_FCFG1
  * SCB_CPUID
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants