flash address 0x1E000 access while using secondary bootloader

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.wsdof.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
6 posts / 0 new
Last post
Ankit
Offline
Last seen:1 year 1 week ago
加入:2017-05-24 07:42
flash address 0x1E000 access while using secondary bootloader

Hi,

I am using the secondary bootloader and my application resides in flash memory. Bootloader header is located at the default location ( 0x1F000 ). I have some application related data, that I am storing at 0x1E000 location in external flash memory. Sometimes I found that my application data is being over written at address 0x1E000. I am sure that my application is not writing any garbage data at that address. So, I want to confirm that is secondary bootloader or BLE stack access 0x1E000 address for own use?

If yes, suggest me the location which I can use for my application.

Device:
LC_Dialog
Offline
Last seen:8 months 4 weeks ago
Staff
加入:2016-09-19 23:20
Hi Ankit,

Hi Ankit,

Please help me understand the question. Your applications has a secondary bootloader. Can you specify where is this secondary bootloader is residing?
In external flash applicaion, the primary bootloader looks at the 0x00 location for the application image. If you have a secondary bootloader, then you can customize your location of the application image in flash memory.

Irrespective of primary/secondary bootloader, all that is done when booting is that the application image is copied on to RAM to execute. So the BLE stack will not access the flash memory. And none of the others parts of the SDK access the flash unless the user application is requesting for a read/ write.

Best,
LC

Ankit
Offline
Last seen:1 year 1 week ago
加入:2017-05-24 07:42
My secondary bootloader and

My secondary bootloader and my application both resides in flash memory. As per my knowledge secondary bootloader stores information of partition like the signature, image partition start address, CRC etc. inside flash memory. I have configured PRODUCT_HEADER_POSITION at 0x1F000. But I found that sometimes my application data which is just 1 sector above PRODUCT_HEADER_POSITION is located at 0x1E000, got corrupted. It is all filled with zeros.

Qinjiny_Dialog
Offline
Last seen:9个月5天前
Staff
加入:2016-11-01 05:47
Hi Ankit,

Hi Ankit,

As far as I know secondary bootloader basically don't write to flash or perform any erase actions. Those addr definitions like PRODUCT_HEADER_POSITION only tell it where to read desired data it needs, secondary bootloader will not write or erase to the flash. The only features in SDK that could manipulate flash content I can came up with are SUOTA and saving bonding info for security needs. Check if anything changes when you disable those features. Other than that you might need to recheck everything about SPI flash handling in your own app.

Ankit
Offline
Last seen:1 year 1 week ago
加入:2017-05-24 07:42
Hi again,

Hi again,

I am still facing this issue. I am doing flash erase, read and write operations.

Do I have to introduce delay after every flash operation? If yes then what should be the delay for particular operation?

MT_dialog
Offline
Last seen:1年1小时前
Staff
加入:2015-06-08 11:34
Hi Ankit,

Hi Ankit,

I dont think that there is a need for appying a delay between the flash operations, there is no delay when the SDK is interacting with the flash, the fact that you sometimes get corrupted data perhaps has to do with the fact that the SUOTA erases each bank before writting the new image, but that would requires a quite large image to reach to the 0x1E000, also if that was happening that would mean that you could easily replicate the issue everytime you wrote in bank 2, additionally if SUOTA was messing with the extra data and perhaps was erasing the data you would see 0xFF and not zeros. If the issue is not replicatable that way that means that your data get corrupted by something else and not by SUOTA.

Thanks MT_dialog