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
STM32F103RBT6_FlashSize.hex
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!
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.