Hello, I'm having an issue with a Portenta H7 board. It came packaged with the Machine Control board and when I first connected the device to a Win10 PC, it didn't enumerate in the device manager at all. When I pulled the board off the breakout and plugged it in directly to USB-C, the LED flashes 4 times long, 4 times short, double pressing reset to put it in bootloader mode still doesn't make it show up in device manager. I Google'd (and searched this forum) the issue and the best it was able to come up with is that the MBed OS layer has crashed and therefore the USB port is now inoperative? But I couldn't find directions/instructions on how to recover from this state.
Before doing this, I was mostly setting up the rest of the hardware that was surrounding the Machine Control board and ensuring connections were solid before doing any programming. I have applied the 24VDC power to the board and cycled the power to the whole system a bunch of times during this bring-up testing. Picture of the overall setup is in the attached picture.
Blinking red LED ("morse-coding") is indication that the HardFault_Handler has been called.
This happens if your FW crashes (you access "forbidden" memory address, instruction failed ...).
In this case: all "dead" (no UART, no USB device, MCU hangs in endless loop with just "morsing" your red LED).
I guess, the "morse code" on red LED might have a meaning (for the reason, e.g. 3x short + long = hard crash). But never mind: when you get a "red morsing LED" - a serious crash and all dead.
Actually, your bootloader should come up again (the green fading LED). But often I had to try several times. Even manual says: "press it twice" - I had to press it several times "twice" until it enters bootloader. Try to press so often that you see it has entered bootloader (this should work even "red morsing LED" was there, but if bootloader not entered (fading green LED), you would crash immediately again (something wrong in your FW)).
BTW: what I have seen on Portenta H7 (and also some other STM boards): you can lose their content, even the bootloader can be lost (the FLASH ROM code ripped out).
I do not think so that bootloader is lost as long as you see a "red morsing led" (good indication that part of bootloader code is still OK).
But for sure: the larger my project gets, the more stuff I do in my project (esp. enabling devices) - it takes more then just a "double reset": often I have to press reset very often, with different frequency (pulse duration) until it enters the bootloader again.
Don't take "press twice" too accurate: "press reset until you see green fading LED for bootloader entered".
It can happen that you brick your board (I did, somebody else as well in forum). If this happens: possible but tricky to recover.
I suggest:
have an external SWD hardware debugger, e.g. ST-Link
with the breakout board it is easier to access the SWD signals (for SWD debugger)
if you connect SWD debugger - you can have a look if bootloader is still there
(worst case: all words on FLASH ROM, 0x08000000...) are 0xFF = erased)
it is possible with external SWD debugger to flash the bootloader again.
But if bootloader is gone - you cannot reactivate the board.
I do not know what can cause to "erase" the FLASH ROM, esp. the bootloader. I know this issue also on other STM32 boards. I could imagine: wrong code, issues with power drops, e.g. to much current drawn, resetting or crashing board during a "critical code execution" (e.g. when writing to FLASH ROM) can "erase" all code from MCU.
Thanks for the insight on how the board works and what happens when it crashes out.
I guess I missed a couple of key points of information in the OP.
I did manage to get it to the green slow pulse that indicates bootloader mode, but the board still doesn't enumerate in device manager or otherwise. I could try with a Linux machine and see if it's any different. But the message I'm taking away here is that if I can get the device to enumerate somehow in the host OS in bootloader mode, I can reset the device? From there, do I flash the "blink" program, or do I have to re-flash the whole stack?
I should have clarified that I have done zero programming to the board, this happened the first time I plugged it in out of the box. Before I plugged it in for the first time, I was doing the activities mentioned in the OP. There were some digital and analog inputs that were live during the hardware setup (24VDC straight into the Machine Control inputs, shorting some outputs to 24VDC to test relay logic, etc.), would that have inadvertently had a negative effect on the board?
Anyways, I've bought another H7 just to see if this was a fluke or if I did something to pooch the board. Expensive fix, but I'm sort of in a crunch to get the overall system up and running for a prototype demonstration. If I'm being honest, the real system will use a PLC, but these things were easier to get my hands on at the time and OpenPLC seemed easy enough to learn. Who knew the hardest part was getting the board connected?
So, I purchased another Portenta H7 board, was able to plug it in and enumerate it on Windows and did some of the basics (blink sketch, etc.) and then was able to compile a program against it and run it without the Machine Control carrier board.
When I tried plugging it back into the Machine Control board, it immediately goes back to flashing the onboard LED red in the SOS morse code fashion.
When I pulled it off the Machine Control board and plugged it back into USB-C, it was able to enumerate again, but I have the feeling that if I left it on that board or connected that board to 24VDC, it probably would've died as well...
Anyways, is my Machine Control board dead, what are the next steps here? I don't think it has any firmware, its just a breakout no?
While I could buy the SWD debugger, learn how to use it, and then attempt to repair the bootloader/interface on the original H7,... it seems like a hardware fault on the Machine Control board killed it? I don't see why I need to invest more resources and effort into getting the device back to a usable baseline after spending a whole bunch on the original hardware? Do I have any recourse with Arduino (the corporate entity)?
I guess: if you get a "red morsing LED" it just means: "your code has crashed and it has entered a HardFault_Handler". Don't give up too early, potentially your HW is still fine (it is potentially just a SW bug).
But if you enter the "red morsing LED" - your bootloader is also dead, or it enters immediately this SW bug state (from your user code) and bootloader cannot be activated.
I do not know: is this the same question about 24V on an MCU pin?
Do not apply 24V! Make sure to have max. 5V on MCU pins, even without any glitches, spikes!
When you apply 24V - potentially you kill the GPIOs of your MCU - I would assume all is dead: the inrush current is so high that potentially all internal logic is "disabled" (bypassed, due to too high voltage seen on any pin).
I would suggest:
a) take the MCU board and try to test with a simple blinking LED
b) check your setup and make sure - never larger as 5V applied to any MCU pin
c) disable almost all in your project and enable step by step until you see it fails
d) when it fails with some specific code: try to understand why it fails, e.g. why it crashes and enters the HardFault_Handler
e) fix the issue, find a work-around (different approach) and try to have a FW which never enters "red morsing LED" (which is for sure a SW bug).
Okay, perhaps... I wasn't... clear? I thought I was, but you never know!
There was NO software or sketch or any kind of other code made by ME on the device as shipped, all i did was setup the rest of the system first, before I started attempting to program the device. To this day, there STILL isn't any of MY software on the device, because as the OP mentions, I HAVEN'T BEEN EVEN ABLE TO ENUMERATE THE DEVICE ON THE HOST MACHINE.
Now onto the DEVICE. The package comes pre-assembled as a H7 Portenta board that has its multi-pin connectors seated into a very larger carrier board that Arduino calls "Portenta Machine Control", or you know, the board that is painfully obviously in the picture I posted in the original post. THAT is the device that I put 24VDC into, expecting that the hardware onboard does the appropriate level of conditioning to make sure that the H7 itself only gets the supply it needs. If the Machine Control board still delivered 24VDC to the H7, then that's not my problem, it would be a design fault with the board. And obviously, I can't fix that.
EDIT: Arduino support actually came through and got me a replacement via DigiKey. Still pending whether or not the replacement is good, but we'll see.
