I am currently trying to get a custom STM32H743 based flight computer flashed with Ardupilot. I didn’t add a USB port, so I am unable to flash via DFU. I do have a SWD port however, and have confirmed that I am able to flash code to it as I have done some basic hw testing for the sensors on-board. I am currently trying to flash the ardupilot_with_bl.hex file using CubeProgrammer. After flashing, I am trying to check if I have flashed it by trying to connect over Mavlink via two RFD900x-US modems. One is connected over FTDI to my pc, and the other is connected to my primary Mavlink UART pins on the FC. After a while of trying to connect it times out. The RFD900x-US modems indicate that there is a link established via a solid green LED, and shows that data is being sent with a flashing red LED, however even with that it still times out.
I am wondering what you all suggest on what my next steps should be. I went ahead and linked my hwdef and hwdef-bl files.
To circumvent any possible issues, I went ahead and used an FTDI cable on the primary mavlink connection established in the hwdef file. When using mavproxy it still is saying it doesn’t see a heartbeat.
Update: When I flash just AP_bootloader.hex. The LEDs configured in the hwdef-bl file turn on. However, when I flash the arducopter_with_bl.hex, they never turn on. This leads me to believe its something with the hardware configuration, so the hwdef file, I do not know what in particular though.
Another update: I got it flashed over linux using my swd instead of trying to do it through windows and it works… I followed the video for the build environment when I first did this so thats really the only thing that changed… I was keeping this up for those who run into the same problems but it seemed to be a simple fix to get this far.
Only problem now is trying to get data from my on-board sensors.
It now seems to not like my barometric pressure sensor. I have read that is probably a hw issue, but I have already confirmed this sensor to be functional already.
I went ahead and got some basic spi check running to see if I can read the chip_id. The baro that im using is the BMP581, so the value for the 0x01 register is 0x50 which is what im reading here. However, in the hwid section I dont see it reading anything about my baro or my imu (icm20948)
Ok so maybe it’s my config, but I am getting a hault message (as seen by the breakpoints) but still receiving messages about the barometer driver not being able to initialize over mavlink to mission planner.
I appreciate that cause im currently pretty stuck… i dont know whats going on with my hw config such that neither of my spi busses even have activity, but im able to talk to it over mavlink. It makes zero sense to me.
As for the gdb/openocd i was trying to get the other version of openocd with the thread fix tridgell was using but i had no luck getting it setup. If you know how to do that step i would appreciate some suggestions on that. I was able to get the debug mode setup as seen in my ss since it can read the symbol table. Another thing with that is that it didnt recognize chibios automatically, i had to set it in the openocd.cfg file and when i did it recongnized it but said it was stalled.
I honestly think i really need to get in contact with a dev and i think if they saw what i was doing they could provide a fix but no luck so far.
Its a separate version @tridge was using for viewing threads on stm32 microproc flashed with arducopter 4.5 or later. I was having some trouble getting it to work within the build//bin file. I got it installed from the repo, but it wasn’t able to find stm32xx.cfg and stlink.cfg files it needs for openocd to work with an stlink. From that point I decided to move on cause I was a bit confused as I hadn’t touched anything but the openocd folder, and I built it using the video you shared.
I went ahead and joined the discord and shared it with him. He hasn’t been able to find anything yet, but we shall see
Oh just an update, I figured out what it was. It was the hwdef file. If you think you’ve checked it, check it again I swear. Compare with hwdef.h as well.
It was really stupid . The spi pins were defined to the right pins in the IMU and BARO definitions and used the right spidevs, but the spi dev spi busses were flipped. I kept on overlooking it…
o
I am now getting a problem with my motors not getting enough thrust… if you feel like being helpful with this as well I’d greatly appreciate it. I don’t have a current sensing or battery voltage sensing input to my FC, is that required for the motors to behave correctly? I assumed if I was just doing stabilization, it would just try to match the input from my joystick (which is in yellow).
. The spi pins were defined to the right pins in the IMU and BARO definitions and used the right spidevs, but the spi dev spi busses were flipped. I kept on overlooking it…
