There seems to be 256kB of extra flash. The program tests only 32kB of it.
More details:
It seems that the STM32 processors are often sold as smaller capacity devices. I.e. the manufacturer does not bother to actually make 256 kB parts separately, but instead sells the 512 kB parts as 256 kB. It could also be that there is some error in the extra flash, which is why it would be sold as 256 kB device - but I have not found any problems so far.
Iām not sure how the bootloader would act on a smaller capacity device, and that is why I only test the 32 kB region corresponding to APP4 in second bank. This way if the second bank does not exist, the test program will not overwrite anything else but itself.
Because the current space per application is only 32kB, the 256kB of extra flash is a big thing.
Heh, and to think that Iāve actually known about this for months now. I just thought that mine was an exception, āsurely not all the processors could have 2x the flashā.
Now we need to see what happens when we upload a .hex tailored to be written there. Itās a matter of changing a couple of lines in the linker script, am I right?
I also tried to write beyond 512 kB. It starts overwriting from the start, i.e. it overwrites the bootloader and you need to restore through serial port.
I suggest a division of the second memory bank:
Any application may use itās own 32kB slot in the other bank, i.e. APP4 can use the normal 0x08024000 and also 0x08064000.
The SYS area in second bank could be used for stuff that is useful for many applications. Graphics routines, libc, better filesystem code. An alternate bios, that is.
The FPGA and LOGO areas are up for grabs, if someone needs even more space. I think the main application (GCC port of it) is the largest, so maybe it could use the 70 kB FPGA area also.
I donāt recommend using the bootloader area. If someone happens to have a 256 kB device, it could overwrite the bootloader.
If we put the main app in APP1 + extra flash, it would also free up APP2 for other programs.
Since the bootloader is the same for all the DSO quads (or at the least the starting bytes are probably the same), Iād implement a check on the start of the bootloader area on bank 2. If it returns random stuff or 0xFF, itās uninitialized flash and weāre good to go; if it returns a known bootloader magic instead, we halt the CPU or abort accessing the extra bank.
While rescuing my Quad bootloader I noticed that stm32flash reported it as 512KB but I thought it was a lie. Unfortunately your flash test wonāt run on it (engineering sample).
Yeah, but if we want to install the programs by using the bootloader (by copying .HEX files as usual), there is no place to add that check. The bootloader happily writes over itself
Thatās how I got the idea also. But after all, what stm32flash reports is half a lie. It can never report ā256 kBā, because all high-density part numbers are hardcoded as 512 kB. I donāt know if the stm32flash maker did this because of the extra flash, or if he just didnāt check.
Do the rest of my programs (frequency response etc) run on it? What happens when you try to run the flash test?
With all that space who needs the bootloader? We can write a custom bootloader to place in APP4 (or do everything with PAWN, if there are flash access functions) and manage flashing and extra app booting from there.
No, I havenāt been able to run anything else than the original (or close) firmware. Now that I have serial access I can do some debugging. But I donāt want to spend too much time on this, only a very few of us have the engineering devices so it would be an effort of limited value. I would rather spend time on porting Pawn to the Nano I asked Seeed on the forum about the HW differences in the engineering samples but I havenāt got any response. I know there are some voltage range differences but that should not concern the firmware too much. I am more worried they changed something with the FPGA so that system BIOS is not compatible. On the other hand I think someone ran 1.08 on them* which also ran on the final HW in which case they can not be totally different, but I am not sure about this and havenāt had time to do much testing. There must be someone out there who knows the details and can save me from fooling around in the dark.
I can now safely assume that most (probably all) DSO Quadās have this extra flash, and so I can make use of it. It would be most annoying if it didnāt work on all the devices, though a workaround could possibly be made even then.
Another interesting piece of information was that all the DSO Quads seem to have ILI9327 LCD, while the original code also supports R61509V.
We can write a custom bootloader to place in APP4 (or do everything with PAWN, if there are flash access functions) and manage flashing and extra app booting from there.
I asked Seeed on the forum about the HW differences in the engineering samples but I havenāt got any response. I know there are some voltage range differences but that should not concern the firmware too much. I am more worried they changed something with the FPGA so that system BIOS is not compatible. On the other hand I think someone ran 1.08 on them* which also ran on the final HW in which case they can not be totally different, but I am not sure about this and havenāt had time to do much testing. There must be someone out there who knows the details and can save me from fooling around in the dark.