Xenon is stuck after Reset

[Montvydas]

Description
Xenon board gets stuck (Green LED is always on and Blue LED fades with ~1Hz freq, the previously uploaded code is lost) after I either press a reset button or upload new code (reset is done automatically after upload). The condition for this to appear is to connect LOW voltage (e.g. GND) to pin A0 (P0.03) prior to reset. On top of that, the application gets lost and no number of resets after disconnecting GND from pin A0 restarts the normal operation. The only way is flashing the sketch again.

Set up

• Xenon board with particle_xenon_bootloader-0.3.2_s140_6.1.1.hex bootloader
• 2015 macbook pro 13" running Mojave
• Serial debug log:
  BSP Library : 0.19.0
  Bootloader : s140 6.1.1
  Serial No : 3171D58826B5BECF

To Reproduce
Steps to reproduce the behavior:

1. Connect GND pin to A0 of Xenon board.
2. Load any sketch from Arduino IDE to the connected Xenon board (e.g. blink).
3. The board should now be stuck, confirm that the uploaded program doesn't run.
4. Disconnect GND from pin A0 and load the sketch again.
5. Confirm, that the board runs as usual.
6. Connect GND pin to A0 of Xenon board again.
7. Press reset button.
8. The board is again stuck.
9. Disconnect pin A0 and press reset button again.
10. The board is still stuck, the only way to restore normal operation is to flash a new sketch.

Expected behavior
If I repeat the steps using any other analog pins A1-A5 the problem doesn't seem to appear, nor does the problem exist when repeating the steps using Particle bootloader. I would expect the board not to get stuck after reset if LOW voltage is connected to A0 pin.

Additional context
Additionally tested Adafruit nRF52840 Express to confirm that the problem does not exist there. Tested all Analog inputs as the wiring is slightly different (A5 instead of A0). Also tested the second Xenon board I had to confirm that the problem is reproducible. I know that Xenon isn't officially supported, but this might be helpful to others or maybe we will even manage to find where the problem lies :)

[Montvydas]

I just checked the bootloader and found this inside the board.h for xenon as well as other boron and argon boards:
#define BUTTON_FRESET _PINNUM(0, 03) // A0

I also found that other boards have BUTTON_2 instead of BUTTON_FRESET and also that later they define BUTTON_FRESET to be BUTTON_2. BUTTON_2 for other boards e.g. Express is chosen as D2.

It is now clear where the behavior I am seeing is coming from. I would still like to know though why pin A0 was chosen for this behavior? I would expect it to be a digital pin like on Express board as there are way more digital pins than analog ones. Plus A0 is usually the primary choice for when using analog inputs, but apparently it cannot be used!

[henrygab]

@Montvydas -- nice job tracking down the underlying code.

I recommend posting your findings and question in the Adafruit nRF52 Bootloader repository.

You might get an answer here, but since it's a ... feature ... of the bootloader, you'd likely get a faster answer in that repo.

[Montvydas]

Thanks @henrygab for your response and indeed you're right - I will try posting this in the Bootloader repo, now that we know that the issue is related to the bootloader itself :)

[henrygab]

@Montvydas -- See also bootloader issue #115.

I had the same issue on my PCA10056, and uploading a single UF2 binary caused the magic "ignore the CRC" value to be written, allowing things to "just work" again.

[Montvydas]

@henrygab -- mhm, sorry but I don't think it's anyhow related, although I did try the steps from your comment just to confirm this by flashing CircuitPython UF2.

I read a bit more of the source code to find that this BUTTON_FRESET (aka Button Factory Reset), which is assigned to A0 for Particle boards is used to initialise OTA DFU updates. To initiate OTA it is required to 1) set A0 to GND 2) press MODE and RESET buttons 3) release RESET button 4) release MODE button. Notice that it's very similar to putting the device in normal DFU mode, the difference being the connection of A0 to GND. Anyway, this procedure will cause AdaDFU device to appear within detected BLE devices (Use nRF Connect app), which can be used to perform OTA DFU updates. Oh and if MODE button isn't pressed at all while performing the same steps, it will perform, as the button implies, a factory reset 💀

I believe that it is an unwise decision to use A0 pin to perform this functionality as 1) there is only that many analog pins that are available, while we got plenty of digitals ones (analog pins can also be used as digital ones), but ok, I will let this one slide.. 2) Analog pin A0 is probably the first choice for 99% of people using ADC (I mean cmon, who uses A1 instead of of A0? 😄) - oh boy they will be surprised when their projects sometimes work and sometimes perform a factory reset.. 3) I believe Adafruit website should point which pin is used to perform factory reset for each board explicitly as otherwise many more confusions will be caused in the future. This is done on nRF51 but I couldn't find any information regarding nRF52840.

Also, I just created a bug on Bootloader repo (Need to Change BUTTON_FRESET Pin on Xenon Bootloader #119), to see what are the others thinking.

[henrygab]

Ok, sorry it wasn't the same simple issue for you. Just wanted to have the potential to save you some time. good luck!

[Montvydas]

Haha no worries, any help is better than no help! Actually, cherry on top, apparently there was a BUTTON_FRESET defined inside variant.h file in this repository too, but... The numbering was wrong, so I fixed (and a couple more mapping issues..) that and it is already on master (yay!)