Can anyone help me make sense as it does not to me. In the above mentioned in DCD class we read: [Note: This is the write method in the public not in private section of the class]
Result write(const Address offset, const void* data, size_t length)
{
if (offset >= Length)
return DCD_INVALID_OFFSET;
if (offset+length > Length)
return DCD_INVALID_LENGTH;
if (!length)
return DCD_SUCCESS;
the first two checks are one stranger than the other and I can’t make sense of them: For starters the first one is implying that the offset of a field in the application_dct_t must not be greater than the size of that field which does not make any sense as they are unrelated quantities. The next check is even stranger: implying the offset of the field added to the length of the field should be less than or equal to the length of the field!!!
Length is not the length (mark L vs l - C/C++ is case sensitive) of the field but the over-all length of the space occupied by all fields and neither the start nor the end of the field are allowed to hang over that limit.
That’s embarrassing. Thanks @ScruffR. Sometimes an extra pair of eyes do wonders. I probably would not have spotted that if I stared at it for another week straight.
While we are on the topic I would appreciate if you or someone could clarify:
Firstly, Is there a reason why every write of any of the application_dct structure elements involves copying the entire current sector to the alternate sector with only the element in question over-writting its own corresponding offset and length, finally invalidating the current sector and on the next write the Sectors get swapped again and so on? Is it to balance the wear and tear of these two FLASH regions?
Secondly, looking at the binary on the Photon on the addresses which correspond to DCD (0x8004000 to 0x800C000) I am trying to figure out where the structure such as applicaiton_dct, etc are and I would have thought finding a valid header with a valid seal or watermark would have been good land marks to look for, but to my surprise I cannot find them, or is there a trickier or more elaborate way to locate them?
First question:
Flash writes can only clear bits but not set them. In order to set bits you need to perform a page erase (setting each and every bit in the page - which is actually the action that causes flash wear) and then clear all the bits supposed to read 0.
For the second I’d have to refer you to @BDub
But I’d guess, since we (or rather the copiler/linker) know where it is we don’t need a mark, since direct access is not the intended way.
While I realize the linker and compiler do all the work in lining up the data bytes I elaborate further in my reply to @BDub's reply post, as I can't make sense of my photon's DCT data. Once I get my head around the right data in the right places, I'll let the linker do the work instead of me trying to line them up
Thanks @BDub. Looks like I am working with an obsolete dct.h, as I checked on the github and you seem to have added extra fields: cloud_transport, a few alt_xxxx fields and device_id (previous device_id changed to device_code).
It seems that the documentation link you posted may need a correction, as it notes reserved2 is 1280 long whereas in the code it is clearly 628!
Having said all of that, my DCT data is still confusing: (Addresses below are offset of 0x08000000):
As can be seen, its data starts only at 0x8009a30 (offset of 0x1a30 or 6704 from 0x8008000) which is clearly way past the end of the DCT structure.
Also I notice my firmware is still monolithic and it has not been upgraded, although I did trying to put it in breathing cyan which is meant to OTA upgrade itself presumably to modular. This is because my module_info reads as (again offset of 0x8000000)
