I'm getting the impression that one should start new firmware projects using the Flash-based Tivaware routines, and then only move to the ROM_ routines after the code has been proven.
I am writing test firmware as part of the hardware verification stage of my product development. I happened to start out using the MAP_ functions in Tivaware driverlib, assuming that Flash usage will be a concern in the future, and also assuming that downloding code changes should be quicker if the driverlib is not compiled into my image.
What I have noticed is that my firmware seems to hang at random, but only with new code that I add. At first, I looked around for all of the usual suspects like pointers and interrupts, but quickly eliminated those. The really strange part is that I'll #if out the problem code and then move on to accessing new peripherals and then after a few revisions I'm able to include the previously problematic code and it works! Only the newer sections cause problems. The fact that old code suddenly works without being rewritten (just being included verbatim to what failed before) is highly frustrating.
Eventually, I decided to stop using the ROM_ functions so that I could step into the driverlib functions to diagnose the problems. I accomplished this by removing the rom.h include, but retaining the rommap.h include. Thus, my code is written with MAP_* but I assume that none of the ROM_* functions are available without rom.h included. As soon as I did this, I started geting compiler errors. I fixed those compiler errors by adding headers for various peripherals that I am using. This seems to have banished the mysterious behavior. I haven't tested things by going back to the ROM, but I assume that the ROM_* code would now work better, now, because I've included all of the necessary headers.
In summary, it seems that the compiler may not be complaining about all of the missing headers when accessing peripherals via the MAP_* macros and when including both rom.h and rommap.h - and my hunch is that the random failures in my code were due to my firmware calling ROM_ functions that did not have proper C language declarations, and thus were perhaps sending parameters to those functions incorrectly, leading to catastrophic failures.
As a result of this experience, my recommendation is that folks creating new firmware should probably turn off the ROM option at first to make sure all of the necessary headers are in place. After comfirming functionality, it should then be safe to switch over to the ROM library and save space.
Is there something that I'm missing? I'm fairly certain that I was not getting any build errors. Code Composer Studio usually refuses to run my firmware if there are serious build errors. I was clearly getting highly suspicious behavior until I put aside the ROM, at least temporarily.
Comments welcome.
