Access bootloader: force into reset/programming mode/boootloader during power up.

[JohnOH]

When LPC devices are programmed to remap the reset pin it is required to apply power and set DTR/RTS in a specific manner to get access to the bootloader in order to program. Provide hardware and software support to handle this switched power capability, used currently as uploader -w while the device is physically disconnected and reconnected. This is particularly relevant to the JN-ESP device where physical disconnection is not obvious.

[jcw]

To add my .02 ... and expand on what I think is the same issue:

An ARM chip which disables its reset pin can only be reflashed in ONE way: power-cycling the chip with its ISP pin set active (i.e. driven low on the LPC's). With an ESP hard-wired to it for uploading, this means that the ESP must not let the attached uC come out of reset until it can do the upload. This need not be the default start-up behaviour, but it is essential to reflash a runanway uC.

Perhaps a flag could be set via the web interface, and stored persistently in the ESP, to make the ESP hold the reset line low in this way the next time it power cycles (only once, then it can resume its normal behaviour). Also, since the target uC probably starts up quicker than the ESP, the reset line must be designed to stay low on power up, until the ESP can control it.

[tve]

Note to self: need to revise start-up order to first read flash, then init gpio, perhaps use flag in flash to determine whether to force MCU reset or not.

[jcw]

To clarify - here's the issue in more detail.

First the boot logic for LPC8xx (and probably other ARM chips): if the ISP is low on reset (power-up or otherwise), the chip enters its ROM-based boot loader.

Runaway is when the ARM chip reprograms its RESET pin to no longer act as reset. Once this is the case, another way is needed to get into the boot loader, and the most obvious (and fail-safe) way is to power cycle the chip with ISP low. In this case, the code in flash never even gets a chance to run.

For the ESP to always be able to get the attached chip into ROM boot mode, it must have a way to recover when the RESET pin is disabled and no longer usable for that purpose.

Here is what I think should be enough:

• power down everything
• make sure the circuit is such that the power-up state of the ISP pin is low
• power everything up
• the attached µC will enter boot mode
• the ESP probably takes a little longer to start up
• it can toggle the reset pin to get the µC out of boot mode
• or it can upload new code first, since it knows the µC is still in boot mode

Either way, the ESP is in full control of the attached µC, which has powered up, but won't do anything else before the ESP tells it to (the ROM boot will wait indefinitely).

When the µC starts up before the ESP, perhaps due to the ESP being plugged in later, there is the possibility of runaway mode. Nothing can be done, other than full power-off of at least the attached µC and then going through the above steps to recover.

[JohnOH]

If one was reprogramming a node at the other side of the estate it would be nice to be able to power it off remotely using the ESP code.

[tve]

With FW 0.10.3 the ESP raises the ISP signal during initialization. I made an experimental code change to set ISP low during init. The result is that after reset the esp chip enables a weak pull-up on all its GPIO pins, including the one used to drive ISP, causing ISP to rise and then drop again when the firmware inits it to low. I further placed a 4.7k resistor to ground onto the ISP line on a jn-esp. That makes the ISP line go up to 600mV for about 350ms during initialization. Seems like the weak pull-up is around 25k. I'm not sure what to do. Two options:

• use a 4.7..10k resistor and live with the power drain
• use a resistor and code the firmware to keep ISP low most of the time, except when wanting to reset the uC without going into programming mode

In both cases it's not clear when the esp should raise ISP. Maybe that's yet another firmware setting?

A problem with keeping ISP low all the time is that any reset of the uC causes it to hang, including a WDT reset (or am I wrong about that?). That seems like a really bad idea to me.

Finally all these things mean that at power-up the attached uC stays in reset until the esp initializes. Not sure I like that in general.

Overall it seems that a resistor to GND and keeping ISP low at boot by default might be an OK state for a debugging board, like the esp-bridge, but not for a permanent install like the jn-esp. Thoughts?

[tve]

This is not going to get resolved for 1.0, postponing to 1.1

[tve]

Closing ticket: there's nothing actionable for me. Feel free to reopen.