I am seeing some issues when using custom fonts and command sets that I upload to a 160x128 OLED panel. I have a program that I wrote to upload individual fonts into slots 201, 202 and 203, along with the capability to upload command sets after these fonts.

I set up my memory map for the MCU as such:

OLED_FLASH_START = 0,
OLED_FLASH_WELCOME = OLED_FLASH_START,
OLED_FLASH_FONT0 = OLED_FLASH_WELCOME+2048,
OLED_FLASH_FONT1 = OLED_FLASH_FONT0+3584,
OLED_FLASH_FONT2 = OLED_FLASH_FONT1+3584,
OLED_FLASH_FONT3 = OLED_FLASH_FONT2+3584,

So I upload my fonts first and then based on the size of the fonts, I add that size to start address of the font and that's where I start uploading my command sets.

The problem I am seeing is uploading command sets seem to somehow mess up the previously uploaded fonts. They don't have any overlapping address so they shouldn't be affecting each other, but they are.

My questions are:

1) When uploading fonts with the firmware command 'SUF'n, does it actually start the font on the memory boundries I've define above?

2) When uploading fonts, does it just act as a 'FLMWR' flash write command and just write the data into flash, or does it do any additional processing?

3) Do writes have to happen on some sort of block boundaries/sizes? If so, what are they?

4) I do wait 40ms between each 64 bytes of data being sent over the SPI. Is there a certain amount of time I need to wait after finishing each flash write before issuing the next write for the next command set? (i.e. to handle that the firmware is outputting the 'Done!' text back to the display)

5) Are there other reasons why writing after the font would clobber other information already uploaded into the flash?

Thanks.

B

1) When uploading fonts with the firmware command 'SUF'n, does it actually start the font on the memory boundries I've define above?
(YES)

2) When uploading fonts, does it just act as a 'FLMWR' flash write command and just write the data into flash, or does it do any additional processing?
(NO, Write data to MCU program flash is little bit different than to flash chip)

3) Do writes have to happen on some sort of block boundaries/sizes? If so, what are they?
(The write block is 64 bytes)

4) I do wait 40ms between each 64 bytes of data being sent over the SPI. Is there a certain amount of time I need to wait after finishing each flash write before issuing the next write for the next command set? (i.e. to handle that the firmware is outputting the 'Done!' text back to the display)
(If you wrote user fonts first then commands set, please wait the module show "Done!" before starting commands set writing)

5) Are there other reasons why writing after the font would clobber other information already uploaded into the flash?
(Please post your code to: question@digole.com, then we can investigate that)

So what would be the proper amount of time to wait after finishing the transfer for a command set? Right now I wait 500ms.

For the block size, does that mean I need to make all my command sets and total font sizes multiples of 64? I have a bunch of really small command sets (like in 10 to 20 byte sizes, with 0xff at the end of them, of course).

Thanks.

B

 500ms is enough I think, I suggest you post the partial of code to us to investigation. 
Figure out the BUG: if you wrote data into the last 64 bytes before an user font's boundry, the exist data around this boundry could be damaged, if you already wrote user font use this boundry, the font's header will be damaged too, we will fix it in next version of firmware.

I wrote user font in 201, which start address at: 2048+3584=5632, if I wrote few bytes start into address 5600, the firmware will erase a 64 bytes space: 5600-5663, then wrote this few bytes, so, the font's data from 5632 to 5663 will be erased too.

 Okay, thanks, this is what I assumed (i.e. there was some bug that was overwriting my data). I have noticed it is dependent on the size of the font, and can get different results based on how I modify the font data (I am using BDF fonts I create and then convert to u8g format using bdf2u8g).

Is there anything I can do about this issue with the 3.4A firmware, because as you know, I have quite a lot of them with this version burned into them?

Can I get the source code to the 'SUF' microcode to look at what it is doing? Since you've said it doesn't do a simple memory copy of the input font data into the MCU's internal flash memory, what kind of changes will it make to the input data? Will it ever write to more memory than the size of the supplied input font data?

Thanks.

Brett

This bug only affect the 64 bytes address after the begining of pointed address, eg, if you start writing data since address 10 to 19, it only erase the data in address 10 to 73, not erase data in address 0 to 9.

1) Don't use this 64 bytes before font's address boundry

or
2) write data (font and commands set) from lower address to higher
No change on data, just because the flash writing process: need to erase a flash block, then write data to the block, the bug is we only buffered the front partial of data in the block, so the rest of partial of data will be lost.

So it is not a 64-byte align, but 64 bytes based on the start address.

I already write my data from lowest address to highest, but I do all the command sets at one time, and I fill in the spaces between the user fonts.

The problem occurs with both flash writes and user font uploads.

I will try and rearrange my memory map so that the command sets leave at least 64 bytes before the user font starting address, so it won't overwrite the start of the font.. and always wrtie the fonts first to MCU flash.

you need to treat the font's downloading and commands set downloading as same, if you download font's in one place, then download commands set later, this bug will also affect, here is an example how to do it correctly:

1) download font 200, it will use 2048~(2048+3584) address range.
2) download commands set if the address is in font 200 address range.
3) download font 201, it will use (2048+3584)~(2048+3584x2) address range
3) download commands set if the address is in font 201 address range.
4) more....

You can't do download font 201 first, then write commands set back in the 200 address range of (2048+3584-64)~(2048+3584), it could erase the 201 font's header.

Also, never use the last 64 bytes in font 203 (address range: 2048+3584*4-64 to 2048+3584*4), it could erase the firmware code either.