So I didnt know about all the problems people have been having with bricked boards do to the pmic settings etc. I see that setting the clock to above 450mhz with stock pmic settings (IE 3v) seems to be an issue amongst other things. Im fairly new to all this especially registers etc not to mention writing code in general. So when I got my portenta I switched to libopencm3 who had limited h7 support so I Forrest Gumped the usbhs ulpi (libopencm3 has no usbhs support) plus the required parts to boot the m4 core etc etc. Heres my fork GitHub - bm16ton/libopencm3-portentaH7: Currently USBHS i2c clock set/get for i2c/qspi and external ram are aorking . So after writing usb2i2c firmware compatible with linux kernel drivers and usb2gpio with irq support using homebrew drivers I was having issues with getting a usb2spi firmware/driver to work so I threw a small volt meter on the 3.3v line (lesson hard learned, lots of my issues stem from bad/low 3.3v) and could see it was 2.9v. Strange thing is that was causing me no problems in the end, and Ive done nothing but experiment always have h7 clocked at 480mhz and f4 at 240mhz and tons of peripherals running, guess ive been lucky. I looked at the mcuboot bootloader code and comments and posts here about the pmic registers and values....Lots of contradictions and confusion. Seems like most people opted for external 3.3v supply? I Simply looked in datasheet and found the two registers that set the voltage out for sw1 and sw2, added 2 small sections to the mcuboot code in app/power/power.cpp
original code was
// SW2 to 3.3V (SW2_VOLT)
data[0]=0x3B;
data[1]=0xF;
i2c.write(8 << 1, data, sizeof(data));
// SW1 to 3.0V (SW1_VOLT)
data[0]=0x35;
data[1]=0xF;
i2c.write(8 << 1, data, sizeof(data));
and changed to;
// SW2 to 3.3V (SW2_VOLT)
data[0]=0x38;
data[1]=0x7;
i2c.write(8 << 1, data, sizeof(data));
// SW2 enable
data[0]=0x3B;
data[1]=0xF;
i2c.write(8 << 1, data, sizeof(data));
// SW1 to 3.3V (SW1_VOLT)
data[0]=0x32;
data[1]=0x7;
i2c.write(8 << 1, data, sizeof(data));
// SW1 enable
data[0]=0x35;
data[1]=0xF;
i2c.write(8 << 1, data, sizeof(data));
and compiled the bootloader. I was too lazy to look for/and wire up my stlink So I ran "xxd -i bootloader.bin" took the resulting output of hex and copied it into the STM32H747_manageBootloader example sketch, in the header file mcuboot_bootloader.h replacing all the hex in that file with the xxd output and also at the very end it says the size I replaced the number with what xxd had output at its end, compiled uploaded and now I have 3.3v where 3.3v should be.
I understand some people cant go that route because they have no voltage at all. Some helpful hints, we have all gotten intimidated by what turned out to be simple stuff when dealing with mcu's and tech, just remember this is one of those situations. I suggest using swd to upload a new bootloader, and to choose your software and/or hardware wisely. Since some of you dont have any voltage on 3.3v line I wouldnt use a programmar IE some/all? blackmagic probes or seggers that refuse to output if it doesnt see voltage, because obviously you dont have the voltage. Simplest is stlink and st-tools or openocd, the mpsse ftdi chips are nice and work well with openocd and dont require input voltage. Other apps when used with stlink may require the voltage as well. If you dont have either of those devices I can highly recommend Versaloon, its old, its incredible, I love it and the source code repo has amazing hidden treasures all thru it. (GitHub - bm16ton/versaloon-git: with patches to (hopefully) fix gui and eventually maybe ports and linux kernel driver for the usb-2-XXX) . Obviously don't forget to power the portenta with an external 3.3v during the flashing. I haven't looked at schematic to see where the pmic is in position compared to the 5v/3.3v lines but I imagine its the only 5v to 3.3v reg on the board. I would say excellent chance the other usb port (if you have a breakout board) can still present the builtin dfu bootloader (untested just a guess) So I usually have a usb cable kicking around that also breaks out 3.3v, I would attach boot pin 0 to 3.3v pin, use a usb breakout cable put 5v to 5v on portenta, 3v3v from cable to 3.3v on Portenta, plus the 2 data lines, reset and look for a dfu device, then just upload the bootloader like any other app using dfu-util . Im sure im forgetting a ton of other useful info but hopefuly someone will find some part of this helpful and maybe get someone away from using an external 3.3v source unnecessarily. Now pardon my language but for me the h7 spi has been kinda a b**ch and I would love to get my kernel driver/firmware for usb2spi working if anyone is interested in collaborating. As stated I have usb2 i2c/gpio/irq/adc/ all with kernel drivers to easily take advantage of all those awesome kernel drivers. Once I get spi working Ill work on usb 2 sdio and the various serial like 1 wire, rs4XX etc. oh and def get gud going on it as well. Libopencm3 doesnt have dma/dmamux support for h7's yet so ill add that somepoint soon and use the g4 version with less dmamux options temporarily. if someone does wanna help and needs dma. Jesus this ended up being wordy probly shouldnt post after a couple days without sleep.