ItsyBitsy m4 Corrupted USB drive / Bootloader

[Govner]

This requires a lengthy explanation to efficiently describe the problem while eliminating all the "did you remember to do this or do that" possibilities. I have a long-time experience with these M4 boards at the user level but have not tampered with or otherwise manipulated the stock uf2 software.

I have integrated the ItsyBitsy M4 to perform certain functions in a multi-microprocessor controller for a NRF24L01 network. For facilitating software updates to the M4, I simply use a USB umbilical that exits the control unit enclosure. Periodically, I will update my software via the Arduino IDE. Normally, that's a routine process and I do it often as features of the network are expanded. This controller and the network have been running fine for about 5 months. I built a second unit that is identical and I use it as a stand-in for the network when doing upgrades. So, essentially, the units are "rotated". The significance of this is that I can have a "pristine" unit for comparison and debugging. Now for the issue:

I had made a couple of simple changes to the Arduino sketch and was beginning the upload process. As is sometimes the case with certain reactions of the UF2/bootloader sequence, it is necessary to "double-click", etc. etc. I've learned all the sort of quirks Windows can present - so this is nothing new. 90% of the time, it's a smoothly flowing evolution. The other 10%, the process might be a little bumpy but it always goes well in the end and my updates upload without issue. (The sketch compiles to about 45K, just for reference.) Anyway, during one of these "10%" evolutions, somehow the ItsyBitsy became "bricked". Though it's true that double-clicking its RESET changes the M4's LED indications, Windows cannot access the H:/ USB / UF2 drive of the M4. Any attempt to probe this drive (which does, incidentally show up in the Windows Explorer), any attempt to examine the drive from Windows throws a "Device inaccessible" error. To exonerate Windows, all I have to do is disconnect this 'bad actor' and connect my UNIT #2 of the exact same configuration as explained, and it behaves just fine and is accessible and the Arduino IDE uploads the sketch. UNIT #1, sadly, no longer allows any access whatsoever to the 'bootloader' though it's LEDs indicate proper responses in every way.

I have read all the documents on the Adafruit site over the past few hours. My question is, first and foremost, do you feel that there is any possible solution to fix what appears to be a corrupt USB/bootloader without having to do a difficult hardware R&R of the M4 and disassembly of my controller's PCB? If not, I'm just trying to get my head around the easiest solution. I'm kind of surmising that if the M4 won't allow access to its USB drive, then there's no way to restore it without having to buy the tools/programmers for flashing fresh bootloaders.

I am just curious if this problem was enevitable because I had probably purchased a ItsyBitsy M4 lacking the "locked" bootloader before the 'fix' was in? ( I just don't want to 'experiment around' with my backup UNIT #2's UF2 or otherwise until UNIT 1 has been restored to normal operation.

Thanks.

[Govner]

One correction to original post above with respect to the LED behavior. To clarify, the LED behaviors are different between good/bad M4s of my controllers. Here's the comparison and possible clues. I can't interpret what this might mean because I don't know the code behind the DOTSTAR color schema.


POSSIBLE CLUE: The DOTSTAR LED when a 'working' M4 is powered-up on external DC (or via USB) shows a shade of violet (internal Red & Blue are lit). Then connecting a USB cable, it remains 'violet'. Subsequently connecting it's USB port, a working M4 REMAINS violet until double-clicking RESET to produce a Green response. By contrast, my 'bad actor' , powers up with a SOLID RED (not violet) and simply connecting the USB cable, it will immediately go to GREEN. (Wierdly, if I don't connect the USB serial cable at all, the led WILL indeed remain PURE RED but can be put in a GREEN indication with a RESET button double-click. .

[Govner]

In the event that the facts I provided indicate that the bootloader is bricked and a suggestion to re-program it is forthcoming, I ordered the J-Link. I tried to read and follow the procedures in the links you provided in the "How to .. bootloaders" learning PDF but it ended with a link to someone's site where I believe a Feather M4 was re-programmed vice the ItsyBitsy M4. I know it mentioned that it pertained to the Feather and that "other boards could be similarly reprogrammed" (or words to that effect) but I may be in over my head without some hand-holding. I'll do my earnest and spend hours trying but I sure hope I can get help learning how to perform the procedure. I could have just bought another ItsyBitsy M4 but as I mentioned, the board has been integrated (i.e. mounted to another PCB) and so is not easily swapped out. I did have the foresight to solder a header so that the SWCLK & SWD connections are very accessible.

I will await your interpretation of the symptoms I outlined in detail earlier and go from there. I appreciate your help.

Thanks.

[Govner]

I ordered your J-Link Edu Mini today. I will study your instructional .pdf in the meantime awaiting delivery. Any advice would be appreciated. Thanks.

[Govner]

I must confess posessing no skillz to re-flash/repair a corrupted bootloader on the ItsyBitsy M4 Express.

The J-Link docs are daunting but I went ahead and bought a J-Link from Adafruit (yesterday) because of the "Learn How to" documentation on the Adafruit site. I only have access to a Windows 32-bit/XP machine right.

Due to the ItsyBitsy M4 bootloader becoming corrupted ('bricked') during a routine upload, I am scrambling trying to rescue a big project with an imbedded (PCB-mounted) ItsyBitsy M4 Express at the heart of the project's hardware.

Can someone with more experience please tell me for certain if I can use Atmel Studio 6.x with J-Link for the task at hand?

Thanks - much appreciated.

[adafruit_support_mike]

I'm afraid we don't know the specific versions of Atmel Studio. The folks at Microchip/Atmel will be able to give you more information about compatibility between the IDE and specific chips.

[Govner]

Thanks Mike.

Having found an answer, I had returned to this post to delete it or at least let you know I'd done that. Surprise: You are working late and replied!! It's almost 3AM here.

I went through all the Atmel documentation for all the Studio 6.x versions and none support the SAMD51Jxxx device as required. So, I'm confident that the answer is 'NO' to my question about Studio 6.x.

My next move is to use my wife's MacBook and try creating a virtual machine (VirtualBox?) and run Studio 7 (the version you folks recommend). I'll try not to be a pest when I stumble and mumble my way getting my ItsyBitsyM4 bootloader working again.

Thanks as always.

[adafruit_support_mike]

Thanks for the follow-up!

[Govner]

Bill,

I expect to receive the J-Link Edu Mini from you next week and I have the VirtualBox and Studio 7 running well within Mac OSX, as best I can tell without the J-Link hardware. In reading over the Adafruit docs about flashing the ItsyBitsy M4 to fix a 'bricked' bootloader, the concept of clearing and setting the fuses begs the question: If the fuse settings guard the section of flash memory containing the bootloader, how is it that the bootloader became corrupted during periodic, routine uploads of code? Is it possible that these boards got shipped without proper settings? If that's a fair conclusion just please let me know since I have a number of these SAMD51 boards embedded / integrated into hardware and steps would need to be taken to re-flash the fuses so this issue doesn't happen to the others. Of course, I'd rather not have to do that but unless the confidence factor is questionable as to the state of the fuses, I must dissemble the units and re-flash them depending on what your experience has been with the QC on the original units. I've had them for 10 months or so.

Thanks.

[danhalbert]

Sorry for the belated reply. There is now an additional link in the troubleshooting instructions to this guide for updating bootloaders, with specific wiring instructions for the Itsy M4: https://learn.adafruit.com/how-to-progr ... ootloaders

[Govner]

F058BFEF-982C-4579-AABA-39969D31403F.jpeg (80.34 KiB) Viewed 194 times

I think I have done everything exactly as prescribed in the Learning Guide for “How to program ...” the SAMD51J19A for the ItsyBitsy M4 Express.

I purchased the accessories from you ( JLink, cable, & breakout).
I purchased and installed Windows 10.
I installed Atmel Studio 7 w/latest updates.
I installed JLinks software and updates.

Everything looks fine until I get to the point of Reading the ItsyB. The parameter you mention

USER_WORD_0.NVMCTRL_BOOTPROT to 0x0F does not accept a hex input. Rather, Atmel Studio displays a different “data window” for this parameter which says “56-kbytes”.

I suspect that either the Learning doc is not up to date or incorrect. There are other issues but could you confirm these for me please. I have done everything maticulously. Wiring is not an issue. This is a documentation or software version issue. Perhaps if you could also include the software versions used to write the Learning doc please.

Stuck.

Thanks..

The photos show a potential issue but likely unrelated. In ‘scoping’ out the hardware, I noticed the CAP misaligned during manufacture. ( It’s the one adjacent to terminals on the reset button.) The good one is also pictured.

F058BFEF-982C-4579-AABA-39969D31403F.jpeg (80.34 KiB) Viewed 194 times

[Govner]

As more clues present themselves, I'll continue posting them FYI in helping solve this. I would really appreciate it...

The J-Link Edu Mini seems to be operating via USB and following the learning guide for accomplishing programming of the SAMD51J19A, all goes as expected up until "READ" ID is attempted. While the voltage window comes up successfully with "3.3V", the following error is thrown by Atmel Studio: (Copied/Pasted here):

----------------------------------------------------------------------------
Reading ARM chip id failed.

Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device
-----------------------------------------------------------------------------

The ItsyBitsy M4 is a NEW one (out of the box, so to speak) and has never been connected or otherwise used before. It is connected as follows:

USB
3V pin: connected To J-link cable breakout Vcc
GND pin : connected To J-link cable breakout GND
SWDIO and CLK connected as shown in your Fritzing diagram

Just curious if the Atmel Studio's SWD clock (default 4 Mhz) is correct?

I've done everything I can think of and am dead in the water at this point. I'll try anything you suggest. The wiring has been checked many, many times and verified. I even changed out the ribbon cable with no difference. I am trusting that the photos in your learning docs are accurate since there is no other way to verify the connector orientations and the J-Link doesn't seem to have any useful markings.

Thanks, I await your help to proceed.
PS: The title of this post is worded poorly. That's not what I meant but I can't edit / correct it.

[Govner]

Here's verification via J-Link's app that the USB connection to the EDU Mini is working:

SEGGER J-Link Commander V6.63b (Compiled Feb 7 2020 17:25:42)
DLL version V6.63b, compiled Feb 7 2020 17:25:12

Connecting to J-Link via USB...O.K.
Firmware: J-Link EDU Mini V1 compiled Jan 7 2020 16:53:19
Hardware version: V1.00
S/N: 801016788
License(s): FlashBP, GDB
VTref=3.275V


Type "connect" to establish a target connection, '?' for help
J-Link>

[danhalbert]

That misaligned cap might be putting the board in permanent reset or some other problem. We're happy to authorize a replacement so you don't need to continue with this other stuff; we could spend time on it but it might not be worth it. Write to [email protected], and cite this thread and your order number.

[Govner]

I know that it's not necessary to set the so-called 'security bit' for this purpose but if it is set prior to shipping the boards, I need to know. From what I have read somewhere, early boards were shipped without protections for the bootloader but that subsequent boards were 'protected'. I'm wondering if, in addition to the BOOTPROT settings, the 'security bit' is also set on some boards before shipping. It's a critical fact as to why my J-Link can't read the contents other than the registers.

I'm learning.