LAUNCHXL-CC26X2R1: build output and oadCreateFactoryImageBackup() imgLen differ

Hi Ryan Brown1 (3460875)

Since my understanding is (uint32_t)&_imgHdr; is gonna be = 0 because we are talking about factory image and since in TI's documentation it says: 

"The Image Length field is the total length of the executable portion of the image in bytes. Image length is calculated by the OAD image tool using the following equation:  imgLen = imgEndAddr - imgStAddr + 1"

I think the line of code you mention is missing such + 1, which in words is 4 bytes.

Don't you agree?

Hi kazola,

I apologize for the earlier assessment, (uint32_t)&_imgHdr; is indeed zero based on cc13x2_cc26x2_app.cmd defining OAD_HDR_START as FLASH_BASE.  This could be a pad alignment issue with the oad_image_tool or I will ask the appropriate owners for more information.

Regards,
Ryan

v5.1.

Thanks for this. The documentation for OAD is better than some time ago but still allow some questions.

No need anymore Jan!

I got it working.

Hi Ryan Brown1

No real solution, I just wanted to understand it! General TI documentation is not bad but, from my point of view, sometimes it misses purpose. In other words, it is more datasheet-like than application-note like.

For example, ProjectZero code. Can be read? Yes. Can be understood easily on the first read? IMHO, nope. On the second one? Nope. On the third you clearly grasp what is going on and the structure but it is sooooo crowded.

For example, function names like:

       ProjectZero_bootManagerCheck()

I think they would be much more easier to grasp their purpose as simply:

       manage_buttons_at_boot()

You need sillier, shorter and clearer names.

As another example, there are a lot of flow diagrams in the documentation. But sometimes it could use some more direct statements such as as:

"Upon a characteristic write by the remote peer, for example a smartphone, there is going to be a callback. This callback enqueues an event, which will be dequeued by the main event loop and the proper handler will be called".

For me, this is generic and understandable. And helps setting a common vocabulary. When the callback function is not called "callback" anymore but something like ProjectZero_paramUpdClockHandler, after a couple hours reading, it is difficult to keep a constant pattern in mind and is not easier to digest anymore.

Also, ProjectZero has 3000, that is 3K lines of code, single file. The combination of comments at the end of the line of a code line, and at the beginning of lines, make it hard to read. However, it is a GREAT project. I know maybe it is not the intended user base, but just think of anyone coming from the Arduino background. That guy / lady is not gonna stay for dinner.

Finally, some things are harder to grasp unless you read the SDK header files. Like the possibility of using SPI middleware memory driver or NVS memory driver. Both can save tremendous amount of time when developing a NOR driver. But, again, since the documentation is data-sheet oriented, not application oriented, takes a while to identify such double possibility, and how easy it is to use it. Again, a great feature, a bit obscured.

For example, the TI designs website, I do not know if it is called like this anymore, is simply great. That book of 25 MSP430 designs for 25 cents, something like this. As another example, the TI drivers examples in the Resource Explorer, simply great, because they go to the point. Understanding how they are used in big projects, a bit more obscure, because of all that long source code.

So, I guess my point is that the documentation and code are almost too complete, sometimes you get lost in them. It is not always easy to immediately detect the most useful of each section. This is my humble opinion and not a complain, since I have built projects and products with several TI platforms. It is just, it could be a bit more easier to separate the things 90% of developers will use since not all of us are genius like some of the guys in this forum

Have a good night!