Nano 33 BLE, problems uploading and running sketch - used to work

I am using a Nano 33 BLE. It was connected to a ST7796s TFT, which I got working with assistance from @david_prentice - thank you David. However, Part of the code just refused to work, and then the SD card failed to read, and then it refused to upload a new sketch.

So I took the Nano out and inserted it into another breadboard with a set of LEDs connected to pins D2-D12 and used the following sketch, intending to find out if I’d shorted a pin:

void setup() 
{
  Serial.begin(9600);
  Serial1.begin(115200);
  Serial1.println("started");

  pinMode(D12, OUTPUT);
  pinMode(D11, OUTPUT);
  pinMode(D10, OUTPUT);
  pinMode(D9, OUTPUT);
  pinMode(D8, OUTPUT);
  pinMode(D7, OUTPUT);
  pinMode(D6, OUTPUT);
  pinMode(D5, OUTPUT);
  pinMode(D4, OUTPUT);
  pinMode(D3, OUTPUT);
  pinMode(D2, OUTPUT);
  Serial1.println("end of setup()");
}

void setLEDs(int fadeValue)
{
  Serial1.println(fadeValue);
  analogWrite(D12, fadeValue);
  Serial1.println("D12");
  analogWrite(D11, fadeValue);
  Serial1.println("D11");
  analogWrite(D10, fadeValue);
  Serial1.println("D10");
  analogWrite(D9, fadeValue);
  Serial1.println("D9");
  analogWrite(D8, fadeValue);
  Serial1.println("D8");
  analogWrite(D6, fadeValue);
  Serial1.println("D7");
  analogWrite(D6, fadeValue);
  Serial1.println("D6");
  analogWrite(D5, fadeValue);
  Serial1.println("D5");
  analogWrite(D4, fadeValue);
  Serial1.println("D4");
  analogWrite(D3, fadeValue);
  Serial1.println("D3");
  analogWrite(D2, fadeValue);
  Serial1.println("D2");
}


void loop() 
{
  int startIndex = 1;
  for (int fadeValue = startIndex ; fadeValue <= 255; fadeValue += 5)
  {
    setLEDs(fadeValue);
    delay(30);
  }

  // fade out from max to min in increments of 5 points:
  for (int fadeValue = 255 ; fadeValue >= 0; fadeValue -= 5)
  {
    setLEDs(fadeValue);
    delay(30);
  }
}

Double-clicking the reset pin enabled me to upload this sketch, but the LEDs didn’t light up. I checked the wiring, that was fine. The programmable LED on the Nano itself was sat pulsing, four slow, four fast… repeat. I edited the code so that only the LED on pin D2 faded in/out. Doing the reset double-click enabled that to upload and it worked. I uncommented the code for the other LEDs connected to the D pins, did the double-click reset and … nothing.

I googled and found: https://forum.arduino.cc/index.php?topic=667985.0
*Lesson 1: Google works and the chances of my problem being unique are small. *

I hooked up my Mega2560 as suggested in the post and edited my sketch to the version shown above - simply rerouting all the Serial.println calls to Serial1.println. After double-click resetting and uploading, then pointing the serial monitor to the output from the Mega2560, I got the following output:

started
end of setup()
1
D12
D11
D10
D9


++ MbedOS Error Info ++
Error Status: 0x80FF0144 Code: 324 Module: 255
Error Message: Assertion failed: result == NRFX_SUCCESS
Locati1 aTGRw1au:xt 0M20 v:srtN-o

The output is as expected right until the MbedOS error. Does that mean pin D8 is broken? Well, no. If I comment out the analogWrite call for pin D12, the output shows D8, and the LEDs connected to pins D8-D11 fade in and out. The diagnostic works fine, unless I call analogWrite on more than 4 pins.

Each attempt shows different values on the final line of the MbedOS error info, but the rest is the same. Going back to Google shows that the error code maps to the lower part of the error status - and decimal 324 is hex 0144. This turns out to be “Assertion failed”, backing up the error message on the second line. I’ve not been able to find out what module has an ID 255, or what NRFX_SUCCESS represents.

So:

  1. Does anyone know what 255 refers to in the module code? Basically, just how badly have I broken this thing?
  2. Is there any chance this is recoverable? It seems a shame to bin what’s at least a partly-working board, but it’s not like they’re expensive and I need to consider how much effort is worthwhile.

Thanks for reading this.

Ian.

ianikrb:
The diagnostic works fine, unless I call analogWrite on more than 4 pins.

Yeah, this is an unfortunate limitation of Mbed OS:

ianikrb:
2) Is there any chance this is recoverable? It seems a shame to bin what’s at least a partly-working board, but it’s not like they’re expensive and I need to consider how much effort is worthwhile.

It’s not clear to me that anything needs recovery.

You will be sure to get an Mbed OS crash from time to time during development, either caused by bugs in your sketch or by limitations of Mbed OS, but it sounds like you already know the double reset trick to put the board in bootloader mode and recover from the crash. After that, it’s just a matter of fixing the sketch so it doesn’t cause the crash.

@pert, thanks for the quick response.

I forgot to mention something.
Lesson 2: Before posting a question, read your draft and then re-read it.
That lesson's for me - not you :slight_smile:

Windows isn't recognising the Nano anymore. It doesn't show up in Device Manager when it's not in bootloader mode, and the following notification appears:

The last USB device you attached to your computer has malfunctioned and it looks like your computer doesn't recognise it.

Thanks for the info though on the 4 analogWrite limit. That must mean that the display I connected, the ST7796s is connecting as a parallel device and using each connected pin to send low/high only

Thanks,

Ian

ianikrb:
Windows isn't recognising the Nano anymore. It doesn't show up in Device Manager when it's not in bootloader mode,

Please try uploading the File > New sketch to the Nano. After doing that, is the board recognized when not in bootloader mode?

@pert, I had to upload the empty sketch first in bootloader mode, because it was sat there with a sketch trying to do analogWrite to 5 pins.

Once I'd done that, yes, it did upload the empty sketch from non-bootloader mode.

I then edited my other sketch so that it just did analogWrite to 4 pins. That worked, in non-bootloader mode. I chose 4 other pins, commenting the first set and uncommenting the new ones. That worked. I went round that loop a few times.

That...that worked.

So, is Lesson 3: If all else fails, revert to the empty sketch and build from there?

Thanks for your help.

Ian

Well, the empty sketch is a good thing to fall back on just to get some understanding of the scope of the problem.

If the Mbed OS and USB is working OK with the bare minimum sketch, and not working with a more complex sketch, then you know the cause of the problem has something to do with the difference between the two sketches. When troubleshooting, it's very useful to have a known good state and a known bad state.

If you were to find that the same problem still occurs even with the bare minimum sketch, then you know that the cause of the problem is completely unrelated to the complex sketch code and you can go hunting for the problem in the system (for example, maybe you would reinstall the Arduino Mbed OS Boards platform via Boards Manager in case that had been corrupted).

I seem to be having this issue, i.e., corrupted bootloader on the Nano 33 BLE. The double tap trick does not put it bootloader mode, no LED light at all (other than the power LED of course).

how do I reinstall the Mbed OS? I don’t see anything in the boards manager for this.

I have Arduino Mbed OS Nano Boards v2.0.0 installed.

would the Tools menu option ‘burn bootloader’ do the trick?

This means the problem is with the board itself, which could be either of the problems listed below:

  • Bootloader program was somehow erased or corrupted
  • Physical damage to the board

If the former, then it is possible to recover, which I’ll explain below.

If the latter, then the only solution is to get a new board.

You should see a “Arduino Mbed OS Nano Boards” option in Boards Manager. The name was changed a few weeks ago.

But since the problem is with the board, tinkering with software installed on your computer can never fix it, so there’s no point in doing it.

If the bootloader program was erased or corrupted, yes. However, it’s not so easy as just clicking a button in the IDE. You need to have the right programmer hardware, and you need to connect that programmer hardware correctly to your Nano 33 BLE. I’ll share a tutorial for how I do this below:

You’ll need

  • ARM CMSIS-DAP compatible debug probe.
  • A way to make a connection to the debug probe. These usually use a 2x5 0.05" pitch header/cable.
  • A way to make the connections to the SWD pads on the Nano 33 BLE. Options:
    • Pogo adapter like https://www.sparkfun.com/products/11591
      Even with this adapter, it’s a bit challenging to get the pogo pins aligned with the small test pads on the Nano 33 BLE, but if you keep at it you’ll get it eventually. Better would be to have a jig like this, but if you’re not going to be doing this regularly then that’s probably overkill.
    • Some people have managed to use a regular 0.1" pitch 2x3 male header pressed down on the test pads to make the connections. I think that would be a bit more challenging, but it’s cheap enough and something you might already have on hand.
    • Soldering wires to the test points.

Instructions

  1. Start the Arduino IDE.

  2. Select Tools > Board > Arduino Nano 33 BLE from the Arduino IDE’s menus.

  3. Select Tools > Programmer > ARM CMSIS-DAP Compatible from the Arduino IDE’s menus.

  4. Make the connections between the debugger/programmer and the Nano 33 BLE:

    Programmer Target
    VCC +3V3
    SWDIO SWDIO
    SWCLK SWCLK
    GND GND
    RESET RESETN

    Here’s the pinout of the test pads on the Nano 33 BLE:
    Nano 33 BLE SWD1. Connect the USB cable of the programmer to your computer.

  5. Power the Nano 33 BLE (you can do this via the USB connector on the board). The debugger doesn’t power the board.

  6. Select Tools > Burn Bootloader from the Arduino IDE’s menus.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.