Need Help: STM32 Trouble Programming  [SOLVED]

Ember
Posts: 28
Joined: Thu Jun 30, 2022 2:48 am
Has thanked: 27 times
Been thanked: 4 times

Re: Need Help: STM32 Trouble Programming

Post by Ember »

Yes, I am in the US (western coast), but I appreciate your offer. I think I am going to pick up one made by adafruit on digi-key
https://www.digikey.com/en/products/det ... 48/6827110
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Need Help: STM32 Trouble Programming

Post by Pete9008 »

That looks exactly the same as the one I have except it's a different colour - but then the datasheet on digikey states the colour supplied varies so it may well be exactly the same one. Surprising as I must have had that one for nearly 10years and I'm fairly sure it was a no brand cheap one from ebay! It works fine here on both the old and new programming software.

The other option is the STLINK-V3MINIE which does seem to be in stock at Mouser. It's an STM part so should be completely compatible with the STM software tools. It's not in a case though so does need a little more care when handling. Sure either will be fine as they both seem to be stocked by all the major suppliers.

Might be worth trying some of the above tests with the one you have first though, it might be fine.

One other point while I remember. I have found that the ST-Links don't like USB3 sockets (the blue ones) on some PCs and seem to work a lot better in the older USB2 sockets. Might be worth checking which you are using?

Edit - Just found a post indicating that the USB3 problem is likely due to a USB 3.0 host controller driver problem, looks like it's my PC that's the problem there not the dongles!
Ember
Posts: 28
Joined: Thu Jun 30, 2022 2:48 am
Has thanked: 27 times
Been thanked: 4 times

Re: Need Help: STM32 Trouble Programming

Post by Ember »

I’m looking forward to tying the program
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Need Help: STM32 Trouble Programming

Post by Pete9008 »

Had another thought related to the missing flash size in the programming software. It's possible that this is an issue with the st-link dongle (but seems a little unlikely as it gets the rest right) or it could be that the chip is returning an invalid chip size when asked. In the later case this could cause the firmware, and possibly the bootloader, a problem as it also reads this size from the chip to figure out where to load/save parameter/pin data. If the value returned is wrong it could cause the firmware to try and access a non-valid memory region when trying to read parameters from flash which would then cause a hard fault and program crash.

Another firmware image attached to test this. This is a v5.24R image configured to run without the bootloader. It also fixes the flash size at 128k rather than trying to read it from the chip. Worth giving it a try if none of the other options give a result. Again file isn't intended to be used to run a motor but just to help diagnose this problem.
stm32_foc_FixedFlashSize.hex
(136.94 KiB) Downloaded 47 times
Edit - Fairly sure there is a chip issue on your board (as well as the issue with the flash size just noticed that the marking on the chip indicates that it is rev2 silicon while the programmer reports revX silicon). If you have a chance could you also try something else, read the flash size register directly through the programmer memory window (read from address 0x1FFFF7E0, size 0x1 in 16-bit mode. It should come back with 0x80 as shown below (128k flash size) but I'm curious what yours shows (wondering whether it will be 0xFF).
FlashSize.jpg
Ember
Posts: 28
Joined: Thu Jun 30, 2022 2:48 am
Has thanked: 27 times
Been thanked: 4 times

Re: Need Help: STM32 Trouble Programming

Post by Ember »

With my verification setting changed to "validate after programming" and the solder ball removed (there don't appear to be any others on the board) The "stm32_foc_StandaloneTestApp.hex" program worked properly and was able to get MG1's and MG2's LEDs to flash. Programming the STMs with the bootloader and foc firmware still didn't work.
The "stm32_foc_FullNoBootload.hex" did not flash either chip's LED, or make the firmware version appear under "Spot Values" on the wed interface.
Using your readback to program my chips was also unsuccessful.
Here are my readbacks from each module after programming them with your readback:
MG2readback_full.hex
(308.28 KiB) Downloaded 50 times
MG1readback_full.hex
(308.28 KiB) Downloaded 42 times
I am not sure where to check for the end of their contents (I assume it's probably pretty simple), could you help with this?
I tried the "stm32_foc_FixedFlashSize.hex" program, and it worked properly for both! I still did not see any firmware version under the "Spot Values" on the web interface.
When I read the flash size register for both chips with your instructions, it did come back as 0xFF!

Considering this evidence, do you know of any ways forward to get functional programing on these chips? At least MG1's LED was flashing when I got the board, but I never used it to spin a motor so I can't say for sure of it worked.

Thank you a ton for setting up these programs, it feels good to know that the LEDs are functional and that the chips can indeed be programmed
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Need Help: STM32 Trouble Programming

Post by Pete9008 »

Well at least a couple of the files did something, I'd call that progress :)

When using the validate after programming option were any errors reported while programming? If not it suggests that the chip does have the full 128k flash and that the flash size register is the main problem. The flash size register should be fixed (factory programmed) and it shouldn't be possible to erase it (0xff is the erased state) but it kind of looks like it has been. I'm wondering whether it could be programmed back to 0x80, if it can then the standard code and bootloader should start working again. Which programming software are you using?

I still need to have a look at your readbacks but need to turn the PC on so will to it in the morning.

What do you get on the web interface when using the fixed flash size image (while the LED is flashing), do you see any parameter or spot values at all? Are you able to post a screenshot?

Edit - just googled this and it seems that some early ST silicon did return an erroneous ff value in the flash size. If this is one of those chips then a firmware mod might be needed to both the bootloader and main code to fix.
Ember
Posts: 28
Joined: Thu Jun 30, 2022 2:48 am
Has thanked: 27 times
Been thanked: 4 times

Re: Need Help: STM32 Trouble Programming

Post by Ember »

Certainly progress :)
When I use your readback to program in "validate after programming" mode, I don't receive any errors, just this:
"00:11:39 : [readback_full.hex] opened successfully.
00:11:39 : [readback_full.hex] checksum : 0x017F2718
00:11:54 : Memory programmed in 11s and 359ms.
00:11:54 : Verification...OK"

I tried accessing the web interface again with he the fixed flash size code on the board, and I must have made a mistake last time because now it is working! There are bunch of (I believe default) parameters, and the spot values, showing version "5.24.R-foc"
2023-03-24.png
2023-03-24 (1).png
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Need Help: STM32 Trouble Programming

Post by Pete9008 »

Fantastic! Glad you've got it working :)

I suppose the next question is where would you like to go from here? In terms of what you have there I can see two possibilities:

1) The chips are very early silicon that doesn't return the correct flash size. It seems ST did release a batch in the very early days that did this and it's possible that someone had a batch that was put back on the market when the chip shortage hit.

2) The chip is not a genuine STM one, if so it is one of the better ones I've seen device marking wise.

Either seem equally likely. The recent chip shortage is the worst I've ever seen which has made sourcing parts almost impossible.

Chip performance wise there is not much to choose between the two. The earlier chips did have a few more errata but I've been using them since 2008 and they have rarely affected anything. If it's not a genuine STM one then it's a bit more variable, some can be good (able to run faster and even fix some of the errata) others not so good. The options are either stick with what you have and see how you get on or swap the chips (they are now back in stock at the major distributors (digikey, mouser, etc)).

In terms of swapping are you able to do it, or do you know anyone, who could do this? Unless you have reasonable experience soldering it's not something I would recommend though. It is possible to do with just a scalpel and good soldering iron but access to hot air soldering kit does reduce the chance of board damage quite a lot.

If you would prefer to stick with the current ones there are a few options. The first is to just use the fixed flash size image. The main problem here is that you don't have a bootloader so will have to disassemble the inverter to update the firmware in the future.

I think the Version 4 bootloader should be immune to this problem (it uses fixed addresses rather than reading the flash size register) and I could do you a revised version of the 5.24 code that would work with it. The same code mod would then need to be done in the source code of any future versions of the firmware too though.

@johu - could this be made standard? - change

Code: Select all

uint32_t flashSize = desig_get_flash_size();
to

Code: Select all

uint32_t flashSize = desig_get_flash_size();
if(flashSize == 0xffff)
	flashSize = 128;
in param_save.cpp, stm32_can.cpp and hwinit.cpp. (Edit - may need to be ==0xff not 0xffff??)

The last option, which is a bit of a long shot, is try to program the system memory block back to what it should be. If this is a non genuine chip I'm wondering if this block of memory has just been implemented as a separate block of ordinary flash memory. If so it might be possible to program it. I'm also wondering whether a full chip erase clears this memory block too - it shouldn't but then it could explain why the board was working when you got it. Here are two files that are images from a chip I have here that can be used to try programming this. One just does the flash size register, the other does the whole system memory block. On my chip when I try to program using them it just reports an error but it might be different on yours?
STM32F103RBT6_SystemMemory.hex
(4.84 KiB) Downloaded 36 times
STM32F103RBT6_FlashSize.hex
(45 Bytes) Downloaded 60 times
If it works it should get you to a point where the standard latest firmware and bootloader work (if the flash size register starts reading back as 0x80 then it worked) - fingers crossed!
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Need Help: STM32 Trouble Programming

Post by Pete9008 »

Ember wrote: Thu Mar 23, 2023 9:21 pm When I read the flash size register for both chips with your instructions, it did come back as 0xFF!
Sorry, forgot to check, did it return 0xff or 0xffff (when reading in 16-bit mode)?

Also forgot to check your readback file, just had a look now. MG2 is fine but there is a section in MG1 that doesn't look quite right (memory address 0x0801E514 to 0x0801E797), it's all 0x00 when it should be 0xff. Might be worth doing a full chip erase, reprogramming my full readback image and then checking the chip contents against my file. You can either compare it yourself (if using stm32Cube there is an option on the memory viewer command dropdown to compare with file) or read it back out again, post it and I'll check it. My guess is that the chip hadn't had a full chip erase before you programmed it the first time.

Now you have the web page working it would also be worth checking that the parameters are correctly being saved to flash. Just change one, save parameters to flash, power cycle everything and then check when you power it back up the new value is still there.
Ember
Posts: 28
Joined: Thu Jun 30, 2022 2:48 am
Has thanked: 27 times
Been thanked: 4 times

Re: Need Help: STM32 Trouble Programming

Post by Ember »

I have been using ST-Link since I was having trouble with the cube programmer earlier. It returned 0xff not 0xffff.
For now I would like to try and make these chips work. Pretty much all of my soldering experience is installing the connectors on this board and some parts of the power stage that were missing. I have a nice station and could purchase some hot air tools—if the chips end up needing to be replaced I’d do some practice and probably take on the challenge, but I’d like to have another board on the way in the mail in case something is damaged.
For these chips, to deal with that lack of a bootloader, I could wire up the pin headers to somewhere near the Inverter’s factory battery input, so that I could connect to the chips through a cap on the inverter and not have to open the whole thing.
I will report here after trying the other few things you mentioned.
Thank you!
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Need Help: STM32 Trouble Programming

Post by Pete9008 »

Ember wrote: Fri Mar 24, 2023 7:01 pm It returned 0xff not 0xffff.
In that case I doubt that programming the system memory is going to work. Worth trying to program the flash size just in case but I wouldn't bother with the other one.

Extending the programming header is a good idea.
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Need Help: STM32 Trouble Programming  [SOLVED]

Post by Pete9008 »

Just realised that not using the bootloader is a bad idea. It sets up the watchdog (hardware that monitors program execution and resets the processor if the code crashes) and without it the watchdog won't be running.

If you find that you are able to program the flash size register then the standard github builds of the bootloader and firmware should start working fine.

If not then the V4 bootloader should work fine with your chips. Below are some builds of the 5.24R main code that should also work with both your chip and the bootloader. I've done three, The first two try to read the the flash size register but if it is invalid then use a fixed size; I'm not sure what is returned when the size is invalid though so there are two version, hopefully one will work. If not then the FixedFlashBootL one should work whatever. You should be able to program these either using st-link :
stm32_foc_DetectInvalidSizeFF.hex
(137 KiB) Downloaded 42 times
stm32_foc_DetectInvlaidSizeFFFF.hex
(137.08 KiB) Downloaded 40 times
stm32_foc_FixedFlashBootL.hex
(136.94 KiB) Downloaded 40 times
If you want to program via the webpage (once the V4 bootloader has been programmed with st-link) you need a .bin file (one attached in case you want to try it):
stm32_foc_FixedFlashBootL.bin
(48.66 KiB) Downloaded 41 times
BTW - if programming from the web page it is best to always rename the file to the same name (stm32_foc.bin) before selecting it. If you don't the old files end up filling up the ESP memory space and once it's full the upload functionality stops working. By always using the same name it overwrites the file instead of adding it.
Ember
Posts: 28
Joined: Thu Jun 30, 2022 2:48 am
Has thanked: 27 times
Been thanked: 4 times

Re: Need Help: STM32 Trouble Programming

Post by Ember »

Success!
With the the ST-Link Reset Mode Settings set to "Software System Reset", and Program and Verify in "Validate After Programming" mode, the Version 4 bootloader and "stm32_foc_DetectInvlaidSizeFFFF.hex" code you sent worked! :D Now both LEDs are blinking, and in the wed interface for each chip I can see all of the default parameters and available spot values, along with the version 5.24 firmware. I plan on test spinning the motos in a Toyota Prius transaxle soon, and I will update here with results.

Thank you for helping me through this!
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Need Help: STM32 Trouble Programming

Post by Pete9008 »

Fantastic, really glad you have got it working :)

BTW - not sure whether you need to load an earlier version of the code in order to use manual mode to test spin but if you do then any version at or before v5.05R should be fine to use on your board with the V4 bootloader (the use of the flash size register only got added after that at commit 869e0b6c.

Hope the test spin proves to be a little more straight forward!
johu wrote: Thu Mar 02, 2023 9:10 pm 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.
@johu - could the invalid flash size mod be made standard? - change

Code: Select all

uint32_t flashSize = desig_get_flash_size();
to

Code: Select all

uint32_t flashSize = desig_get_flash_size();
if(flashSize == 0xffff)
	flashSize = 128;
in param_save.cpp, stm32_can.cpp and hwinit.cpp.

We've had two board that have showed this problem now, and I'm guessing there will be more out there, so it would seem worthwhile. I don't think it's that uncommon, if you look at the openocd code it has this fix in it too https://github.com/openocd-org/openocd/ ... stm32f1x.c, line 981
User avatar
johu
Site Admin
Posts: 5683
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: Need Help: STM32 Trouble Programming

Post by johu »

Oh, now I understand. I think I'll patch it straight into libopencm3, from there it should propagate fastest
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Pete9008
Posts: 1801
Joined: Sun Apr 03, 2022 1:57 pm
Has thanked: 102 times
Been thanked: 347 times

Re: Need Help: STM32 Trouble Programming

Post by Pete9008 »

johu wrote: Mon Mar 27, 2023 1:44 pm Oh, now I understand. I think I'll patch it straight into libopencm3, from there it should propagate fastest
That would be great. I hadn't thought of putting it in the library but it's a much neater solution.

Is it worth changing the desig_get_flash_size() function so that it accepts the default flash size as an argument? Means that the program can control it rather than having it fixed/buried in the library.
Post Reply