Need Help: STM32 Trouble Programming [SOLVED]

[Ember]

Hello,
Working on my first conversion, hopefully this isn't a stupid question--I don't want to waste anyone's time--but i have been looking around on the forum and haven't been able to figure out my issue.
I bought a completed dual motor gen 3 Prius Inverter board from Damien, but while following the wiki's instructions I (stupidly) started the STM32 Programming. Now I can't seem to get it working right. I am not getting the blinking LED or the wifi from the STM32. I have watched Damien's video on programming these boards and followed the instructions on the wiki.
Here is a video of me doing the procedure:
(2:26 min)
I am wondering if anyone can see something that I am doing wrong?
Could there be an issue with my ST link or my computer?
How easily could i have damaged the STM32?

I appreciate your guys' advice/time.
Thank you

[bexander]

I think you need to check the option "Skip Flash Erase" when doing the FOC upload, otherwise it erases the previously uploaded boot loader?

[Ember]

I think you need to check the option "Skip Flash Erase" when doing the FOC upload, otherwise it erases the previously uploaded boot loader?

I just tried that, it did not solve the issue

[lsh3rd]

For the Wi-Fi what happens if you swap the Olimex modules? Does the problem move with the module? The reason I ask is that there has been complaints that these modules are quite failure-prone.

The web site is hosted within the module itself (and it negotiates the parameters with the STM32), so you still should be able to connect to something regardless of the STM32 status.

[bexander]

It was a long time ago a played with this but if I remember correctly you might do a partial flash erase between bootloader and program, to clear all sectors where the program ends up. Anyone else who have done this more recently?

[Pete9008]

Your process looks right. I would expect to do a full chip erase (just to clear any protection flags that may have accidentally been set) , program the bootloader and then program the main stm32 foc code (both without a full or partial erase). Which code are you downloading, where did you get the files?

It is always worth unplugging the programmer and doing a power cycle after programming just to make sure the micros have had a reset and the debugger isn't loading anything.

On the hardware I noticed that both processors appear to have been reworked, is this something you did?

Did you have both flashing leds when the board was first powered up? If so what has been changed since (comprehensive details please).

As mentioned the ESP and STM should run independently of each other. You should get the WiFi if the ESP works regardless of whether the STM is running. You should get the STM blinking led regardless of whether the ESP is running. This suggests that there are either two problems or one problem that is affecting the comms lines between the two (later seems unlikely but possible).

If you unplug the ESP does the STM led start blinking?

Do you have any test kit? Multimeter, scope, lab power supply?

If you have a lab power supply it would be worth testing the ESP module on its own to see if the WiFi and web page then appear. (while you could try swapping ESP modules there is a very small chance that there is a fault on one that has damaged the other, highly unlikely but it is why I would try to test it on its own first if possible)

Really need more information to have a chance of diagnosing!

[Ember]

Thank you guys a lot for the detailed responses.
It turns out that I am getting the wifi that I am supposed to. I knew that the modules put out wifi called "inverter" with a password of "inverter123" but in the wiki it says there should be a wifi titled "ESP-..." which is why I thought that I was missing something. I assume that when Damian had to update the wifi modules with a password, the name changed and the wiki was not updated. (if so, should I update it?)
I am only getting one wifi network, should I be getting one from each Olimex module?

I got the bootloader from here: https://github.com/jsphuebner/tumanako- ... r/releases
and the foc firmwear from here: https://github.com/jsphuebner/stm32-sine/releases
In Damien's programming video ( he uploads both the bootloader and the firmwear via the ST-Link in .hex formats. I tried this but did not get my LED to blink. In the wiki it says to upload the bootloader via the ST-link and the firmwear via the web interface in .bin formats. When I tried this my second LED stopped blinking . So now neither STM32 is properly programmed. I could not find a way to erase the firmwear uploaded to the web interface to reset it to how it was before the second LED stopped.

For a power cycle, would I just be applying 12v via the IDC connector, or would I need to do something else as well?

In terms of hardwear, I have not touched either STM32

If I unplug the ESPs the LEDs do not start blinking.

I don't have any specific test kit, I have a multimeter and 12v and 5v bench supplies. I can buy other tools if you think that they would be useful.

When I got the board I believe that both LED's were blinking when I first applied power (one certainly was), things got screwed up when I tried to upload the bootloader the first time in the .bin format via the ST-link because I was trying to perfectly follow the wiki instructions and was not aware that I didn't need to do that.

I am also having an issue with the IC17 on the board which is part of the power supply in the schematic (https://github.com/damienmaguire/Prius- ... ematic.pdf) It gets hot and only occasionally puts out the -5v where it should on the board, so I think I need to replace it. It was one of the few unpopulated pieces when I got the board, so I had to order one. However I don't think it would affect this issue.

Since when I tried to upload the firmwear via the web interface it screwed up the second STM32, maybe there is an issue with my files/computer? I will try the process with a different computer when I get the chance. I don't know if there is a way I can start from scratch programming both the STMs and the ESPs, but maybe that would be a good idea?

Thanks Again

[lsh3rd]

You should be getting two separate networks in your Wi-Fi list... each module is a unique network and you'll need to attach to them one at a time depending on weather or not you are configuring MG1 or MG2.

[Pete9008]

It does sound like it is the programming that is the problem. Hex should be easier as it takes care of the flash address the program is loaded to. You can use bin but then you have to set the address each file is loaded at (think it's 0x08000000 for the bootloader and 0x08001000 for the main app, you should see those values being automatically set when using hex).

Are you able to post a close up picture just showing the STM chip, or check and post the part number on the top of it? It would also be interesting to know what the st-link identifies it as. Some chips need slightly different programming algorithms so just want to check what part is fitted.

Edit - also worth having a look at this thread https://openinverter.org/forum/vi ... p=45539 . If it's the same problem then using the stm cube programming software may help.

[lsh3rd]

I agree with Pete's assessment. I'm assuming that your MG1 stage's HW is not the cause since that was previously blinking. As such we should probably focus on making that stage work again before moving onto MG2 (though they should be functionally identical). I think we can isolate this to being the fault of the programming or process since the HW as previously flashing the LED.

Someone correct me if I'm wrong, but I *think* you should be able to communicate through the Wi-Fi module to the bootloader if only the bootloader is flashed. I'm suspecting that when you write the main firmware you could possibly be overwriting the bootloader. You could try writing the bootloader again, connect via the web interface, then try and push the foc firmware over-the-air. This process would most definitely not overwrite the bootloader, so it is a worthy test of my theory.

I could try some experiments on my spare board, but it'll be a few days before I can get to it due to a home project. FWIW, my board is the J Williams "small" dual motor variant (not in Damien's store) ordered directly from JLCPCB. In my efforts to flash the board, I did use the STLink for all flashing efforts and didn't have an issue. I did at one point confirm OTA FWDL did also work, but the sine FW was already programmed at that point.

[Pete9008]

Someone correct me if I'm wrong, but I *think* you should be able to communicate through the Wi-Fi module to the bootloader if only the bootloader is flashed. I'm suspecting that when you write the main firmware you could possibly be overwriting the bootloader. You could try writing the bootloader again, connect via the web interface, then try and push the foc firmware over-the-air. This process would most definitely not overwrite the bootloader, so it is a worthy test of my theory.

The communication with the bootloader is pretty limited, it uses a different comms protocol to the main code. There are no parameters or anything similar in the bootloader that can be read out though the web interface. If the bootloader appears to be work you can be reasonably confident that the comms are working.

My suspicion is that it is a high density device fitted to the board (see link in above post), or possible a GD32 rather than the normal part due to recent chip supply problems. If it is then the bootloader won't work as the flash block size is different. If this is the case then the first thing I'd try is to use the later STM cube programmer which seems to be a little better at identifying/programming the target chip.

[johu]

Indeed if you program just the boot loader the wifi module will be able to flash the actual firmware as the processor is in a watchdog reboot loop.

I need to try the boot loader on the GD32. It *should* be able to handle different page sizes - theoretically.

It writes 1k blocks and only issues the delete command if the flash contains something else than all 0xff. So even if the block size were 8k it would only delete the page once and then write subsequent 1k chunks.

[Ember]

It looks like I need to add power to the ESP modules from a capacitor, this may be why I am only getting one network. After this weekend I will be back home with a 12v supply again and will test both modules.
Here are photos of MG2 chip, MG1 chip, and info from the ST link:

I red through the forum Pete linked; the ST identifies my chip as a medium-density and is ST branded.
I'll try loading the bootloader and firmware the few different ways mentioned and get back here. I can also get a cube programmer if you still recommend trying it.
Thanks for the help!

[Pete9008]

Those look like the correct, genuine STM chips and they are reading correctly so it looks like this is a different issue to the one on the linked thread. In that case I doubt the cube programmer will be any better.

The cap is well worth a try.

Agree with Lsh3rd's suggestion that the next thing to try is to program the bootloader using st link and then try to download the main foc code via the web page.

BTW, it is possible to read back the flash memory using the st link, or verify what is there against a file, so it is quite easy to check whether you have overwritten the bootloader.

Also, don't try powering the ESP modules from a 12V supply. They need a 3V3 supply.

[Ember]

Sorry for the delay since last post. I've spent some time working with it and here is what has happened:
wifi modules: both appear to be receiving the necessary power supply, and I can connect to both individually (i.e. only one on the board at a time). When both are on the board, I still only receive one network and cannot differentiate between MG2 and MG1. Does anyone know if this is normal? I think this is how I got my MG1 un-programmed--by accidentally loading firmware onto it when I was trying to connect to MG1.

STM32s: I have tried flashing the bootloader then uploading the firmware over air on both, with no luck. I was receiving this messaging when installing the bootloader:

Then I changed target settings from "Hardware Reset" in Reset Mode to "Core Reset" per the image in the wiki of settings to follow. After that I started receiving this:

, even when reverting settings to "Hardware Reset"

Is it possible that I damaged the STMs by overwriting them when they were already programmed? Honestly I'm a bit out of my wheelhouse here, with most of my experience being mechanical, it might make the most sense for me to buy another programmed board from Damien to keep my project rolling.
Thank you all for the advise.

[royhen99]

Use software reset as without the nrst pin connected HW reset will not work.
Under wifi settings ( AP SSID ) you can set a name for each wifi access point, eg inverter1 and inverter2.

[Pete9008]

I'm starting to get a bit suspicious about the power supplies on this board, especially with your comments about IC17. Could you measure the 5V and 3V3 rails with a multimeter on both DC and AC ranges, ideally with neither ESP fitted, then one and then both.

If everything is working right you should see 5V/3V3 DC and a low value AC (10-100mV) in each case. If the rails are struggling then the DC value will drop and the AC value increase.

The ESPs are quite a heavy load on the 3V3 rail. If you program both the bootloader and main code with the ESPs unplugged does the board LED flash (unlikely but worth checking).

It would also be worth cleaning all the excess flux off around the STM32s, IPA is the safest thing to use. I doubt it is causing a problem, but it is just about possible that it might affect the crystal oscillators and prevent the processors from running the main code (stlink programming is normally done using the internal RC on chip oscillator so that would still work). I've never had a problem with it but then I usually clean the flux off as soon as soldering is finished and cleaning flux seems to have fixed a problem in another thread.

[Ember]

I was able to get that excess flux off of the board, and I renamed each ESP network so that they can be identified (I can now connect to either while both ESPs are installed).
I just replaced the MAX735CSA+ on IC17, now I get a consistent -5V and it is not heating up a lot like the old one did.
The 3V3 and 5V rails are steady at 3.3 and 4.9V respectively, with one, none, or both ESPs installed.
I tired uploading the bootloader and firmware without the ESPs installed, but had no success.

[Pete9008]

Great news on the -5v, not so great on the rest though

I'm sure this must be something simple. The next thing to check is probably the bootloader, which version are you using, have you tried any different versions? (long shot but may be worth a try?)

Do you have a USB to 3v3 ttl serial dongle there? If so it would be possible to connect it up in place of the ESP module to see if the bootloader is running correctly.

With the bootloader programmed using the stlink (and with the stlink then unplugged and the 12v supply to the board powered down and up again) what happens when you try to load the main firmware via the ESP web interface?

[Pete9008]

I'm starting to think that your chip might not be a genuine STM one again (as per the above post and link). If so it's a better copy than the one in the above thread but it still doesn't look quite right. This is a picture of one I have here (on a genuine STM dev board and made before the chip shortage so pretty sure it's genuine - it also looks identical to other ones I have on other old boards):

Compared to yours the text just looks cleaner and better defined, there are slight differences in the package, font and the logo too. Not conclusive either way though. Might be worth taking another picture of yours now the flux has been cleaned away - the device markings might now be a bit clearer?

If it's not a STM chip then a compatibility issue with either the programmer or bootloader could be the problem. I'd suggest that you install the later STM32Cube programmer (https://www.st.com/en/development-tools ... eprog.html) and give that a try to program both the bootloader and the main code.

The other option, if it helps, is I could knock up a quick test app. Just something that would run independently of the bootloader and flash the LED, first running on the internal RC oscillator and then setup the clocks and external oscillator and flash the LED again. It would prove that the processor could be programmed, comes out of reset and run code and the external crystal is operational but that's about it.

[Ember]

I have been using the latest bootloader from here: https://github.com/jsphuebner/tumanako- ... r/releases
I just tried using the Version 4 bootloader from the same source, but with no luck.
On MG1 (where I know that I once had a blinking LED) I tried loading the bootloader, doing a power cycle, and then uploading the firmware on the ESP with the ST-Link disconnected. I did this with both the latest and 4th Version of the Bootloader. When I upload the firmware, a green light momentarily comes on the ESP, but there is no other sign that the STM32 has been programmed, and the Spot Values on the wed interface do not show a firmware verson like they are supposed to, according to the wiki.
Here are photos of MG2 STM32 and MG1 STM32:

It seems like the markings have become more faint after being cleaned with IPA.
I tried using the CubeProgrammer, but it was not consistently connecting to my ST-Link (Sometimes it would take a few refreshes) and it was unable to identify or update the firmware on my ST-Link. This makes me think that maybe I should buy another ST-Link and see if it works better.
I don't have a USB to 3v3 ttl serial dongle, but I can purchase one.
I appreciate your offer for a test app. I think I would like to get the CubeProgrammer working and make an attempt with it before asking you to invest your time in writing something.

[Pete9008]

I ended up doing a test app anyway - I've been meaning to get to grips with the bootloader for a while now (so far everything I have been doing directly programs the board from the IDE) so this was a good excuse to have a look at it. The test app is pretty quick/rough bodge but seems to work, it just flashes the LED 5 times following reset/power up (while still running on the internal oscillator), then configures the external oscillator and the chip clocks and flashes the LED again (faster this time as the chip clocks are then running a lot faster). Nothing, apart from the clocks and the one LED GPIO line is configured. It's a very minimal test but if it works it proves that you can program the chip, that the micro is able to run code, that the external crystal oscillator is working and that the LED works.

To use it just program this to the chip:

stm32_foc_StandaloneTestApp.hex

(68.5 KiB) Downloaded 48 times

This is actually based on the latest FOC code so while doing it I also built the FOC code in a way that will run without a bootloader. Note - this is no good for normal use as without the bootloader you can't update the code without plugging in the ST programmer (I'm also not sure whether saving parameters to flash will still work - I think they will) but it would be interesting to see whether the board comes to life when using it and whether parameters/spot values then appear on the web interface:

stm32_foc_FullNoBootload.hex

(133.95 KiB) Downloaded 39 times

I've tested these on a STM nucleo board using both the built in ST-Link debug and with an old 3rd party debug probe I found in the cupboard:

This is how the STM32F103RBT6 showed on the old ST-Link programming software:

And this is what it looked like in the STM32Cube programmer:

Note - both these were with the Nucleo board debug adaptor, sorry forgot to take a capture with the 3rd party one but think it was the same.

While there I also used both tools to program the latest bootloader and FOC releases. In all cases it programmed fine and the LED started flashing. I also read back the full Flash after programming, the file produced is below. It can be used either to compare the to the contents of your chip (can do in both tools but easier in the STM32Cube software) to check whether your programming is giving the same result (if it doesn't then please save your chip contents and post as I'd be interested to see what's gone wrong), or to program the chip in a single operation (as it contains both the bootloader and main code images, both in the correct places in memory). Here is the file:

readback_full.hex

(304.26 KiB) Downloaded 41 times

A the moment I'm thinking that either the chip or the programmer is the problem. The 3rd party programmers can be a bit variable so I normally use a genuine STM ST-Link/V2 debug interface (although they do seem difficult to get at the moment). Having said that the 3rd party one in the picture updated to the latest firmware first time and then worked fine with both the old and new STM programming tools. It might be worth you trying another to see if it makes any difference, especially as it doesn't sound happy updating to the latest firmware.

Worth noting that the debuggers built into the Nucleo boards can be separated from the main board and used as stand alone programmers with any STM chip. Being STM parts compatibility and reliability is good, and they are still available but are a little more hassle to setup and use.

BTW - There is what looks like a solder ball visible on your second image above (next to the resistor just above the processor). These can sometimes be produced during soldering and need to be removed otherwise they could cause shorts. Worth checking over the board to see if there are any more too.

[Pete9008]

Just noticed that in your programmer screen shots the flash size is being reported as unknown, on mine it correctly reports as 128k. Now this could be a programmer issue but it's more likely to be an issue with the chip. It's possible that it doesn't contain the full 128k of memory and if that is the case then it could explain why the main FOC code doesn't run (if that's the case then my test app should still fit and should run ok).

It would be interesting if you could program the device with both bootloader and main code (either using the same method you have used above or my single image) and then read it back out via the st-link software? To read it back out set the memory address to 0x08000000, the size to 0x20000 and press enter, that should read the chip data out and into the Device Memory window. Then go to File, Save file as, save it in hex format and post here. (I'm wondering whether the contents will end at either 32k or 64k instead of the correct address)

Edit - Could you also change your programming settings from validate during programming to validate after programming (the latter is more sensitive to blocks being overwritten) and try programming again using my single image file?

[Ember]

Thank you for doing that!
Yes I will do all of those, I am going to try and find a genuine ST-Link as well. I will not be able to work on it until Wednesday, but I will send updates then.

[Pete9008]

No problem, hope it helps.

Guessing you're in the US? Shame you're not closer as I have a spare ST-link (from a Nucleo board that I robbed the processor off) that you would be welcome to.

I'm sure a lot of the third party ones work well, they are pretty much the same internal circuitry as the STM ones, it's just a case of finding a good one.