0
\$\begingroup\$

I'm making a device based on the Atmel ATSAM4S2B mcu, and I want the user to be able to update firmware if they want. For this they need to be able to erase the flash to enter the SAM-BA bootloader that can flash the chip over USB.

At first I was going to add a pin header on the board that can be used to short the erase pin to 3.3V by moving a jumper. But this requires them to open up the case to expose the PCB, risking ESD damage and increasing cost and so on.

So I thought of coding a software erase by tying a GPIO pin to the erase pin and setting it high when a certain command is written over USB. But it just gave me pause.. Is this a good idea? Can it lead to the MCU erasing itself accidentally? I checked with an oscilloscope and GPIO pins seems to output some voltage for around 25ms when powering up and also a small spike when shutting off. However the datasheet of the MCU says that the erase pin is debounced to the system clock and also needs to stay high for at least 200+ ms to activate. So in theory it should be fine, but I can't help thinking I might be missing something. Can someone offer any insight?

\$\endgroup\$
  • \$\begingroup\$ As soon as you put the thing into reset for programming, it'll clear the state of the erase pin, won't it? \$\endgroup\$ – pjc50 Jun 28 '16 at 13:42
  • \$\begingroup\$ Yes but that's okay I think, once it has been erased the pin doesn't need to stay high, it then boots to the SAM-BA bootloader forever until it has been re-flashed \$\endgroup\$ – GrixM Jun 28 '16 at 13:46
  • 3
    \$\begingroup\$ If I've read the data sheet correctly, you can activate the bootloader from software by just "clearing GPNVM1": "Setting GPNVM1 selects the boot from the Flash. Clearing it selects the boot from the ROM. Asserting ERASE clears the GPNVM1 and thus selects the boot from the ROM by default." \$\endgroup\$ – pjc50 Jun 28 '16 at 14:04
  • \$\begingroup\$ When I'm worried about undefined GPIO states and have plenty of board/logic real estate, I'll control vital lines with two GPIOs into something like an XOR gate so that I need to set them opposite to trigger my desired logic. \$\endgroup\$ – scld Jun 28 '16 at 14:27
  • 1
    \$\begingroup\$ @pjc50 Wow I was aware of those control bits but I didn't even consider that they would be writable directly from the firmware without the use of the erase pin, but indeed they are. That renders the question moot. Thanks! \$\endgroup\$ – GrixM Jun 28 '16 at 15:10
1
\$\begingroup\$

You could use a sized ceramic capacitor to GND to debounce the spike period. This will mean you have to set GPIO High and wait a bit for the line to come up.

Beyond that, depending on how close to 3V3 the flash chips needs to be (some are ok with 70% of VDD), you could use a weak pull-down resistor to keep it low.

Assuming a 50K internal pull-up resistor on your GPIO pin, a 150K external pull-down will allow you to pull up the line to 2.45V or 75% of the VDD and still keep the line from 'floating high' somehow when not being directed high for erase.

One thing for sure, don't route any other PCB traces parallel and near by as the cross talk can set your chip to erase mode at random.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.