Some of the processors used in the DSO Quad seem to have some extra flash space, that is currently unused. It would help a lot in my development efforts if a few people could try this out:
kapsi.fi/~jpa/stuff/other/FLASHTST.HEX
It installs as APP4, and should print something like this:
LCD type is 02049327
Official flash size: 256 kB
Test complete: extra flash at 0x08064000 works.Please tell if you get the same output 
No problem
I get exactly the same output.
Exact same output here also.
Same output.
How much extra flash are we talking about?
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.
Huge, I would say
All my hats are tipped to you. This is the breakthrough we needed.
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”.
Good thing that I decided to check wider 
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?
Yeah, in fact the .HEX I posted already writes there.
Linker script (.extra is the new section):
svn.kapsi.fi/jpa/dsoquad/test_f … s/app4.lds
svn.kapsi.fi/jpa/dsoquad/test_f … s/main.lds
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:
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.
Just tested mine which is about 2 months old, metal case version and can report that extra memory is reported as working on that.
My DSO says this
LCD type is 02049327
Official flash size: 256 kB
Test complete: extra falsh at 0x08064000 works.
So, I guess, I can help testing out new features you might want to test.
I get the same output. I wonder if there is anybody who did not get the same. Maybe we should test the rest of the usable extra flash memory.
Tested on Hardware Revision 2.7B:
same here
LCD type is 02049327
Official flash size: 256 kB
Test complete: extra falsh at 0x08064000 works.
Pleased to say mine indicates the extra flash is working too