• Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 1382 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

discrepency between driverlib code and driverlib in rom code.

Eric Decker
Expert 1420 points
Other Parts Discussed in Thread: MSP432WARE

I am have pretty significant doubts about what code is going into the ROM area on the MSP432P401R.  I am using XMS432P401R Rev C on a MSP-EXP432P401R launch pad board.  Not sure what is actually burned into the ROM.

But I've downloaded msp432ware 3.50.0.2 (which from what I understand is the latest).   This is supposed to include driverlib 3.21.0.5 which according to the header in driverlib.h is indeed 3.21.0.5.  Here is the structure of the files I'm looking at.....

Now if I look at what is in driverlib/driverlib/MSP432P4xx/dma.c and compare against what is in driverlib/rom/MSP432P4XX/driverlib.c there are significant differences.  If I'm looking at dma.c vs. the dma parts of driverlib.c, I see things  like:

notice the Hungarian notation on the right.  This is rampant throughout driverlib.c.  If this is what is in the ROM it very clearly doesn't match what is in main area of the driverlib.

thoughts?

eric

  • Guru 302700 points
    The ROM driverlib is an older version.

    This code accesses the same register, and the generated machine code should be the same, too.
  • TI__Mastermind 31695 points

    Hello Eric,

    The ROM code that you have in your driverlib.c file might differ in notation, however it should be binary compatible with the the code that you see in the individual peripheral source files. Between the time that the ROM image was made and the DriverLib was released the code was changed to be in a "CMSIS standard" code format instead of the mixed Hungarian notation that you see in the ROM driverlib.c file. 

    As far as being able to tell if the ROM code is actually being reached, as long as the TARGET_IS_MSP432P4XX is defined in your project settings the ROM functions should be available. To give a bit of background, you can see the following lines of code in the"rom.h" file"

    #if defined(TARGET_IS_MSP432P4XX)
#define ROM_ADC14_enableReferenceBurst                                        \
        ((bool (*)(void))ROM_ADC14TABLE[20])
#endif

    Additionally, in the rom_map.h file you see the following type of defines:

    #ifdef ROM_ADC14_initModule
#define MAP_ADC14_initModule                                                  \
        ROM_ADC14_initModule
#else
#define MAP_ADC14_initModule                                                  \
        ADC14_initModule
#endif

    This makes it so that if you call the MAP_FooBar  functions, it will automatically call the ROM function if available. This allows TI to "patch out" functions that might have issues in ROM by simply releasing another header file. Note that if you call the ROM functions the compiler will not be able to inline function calls. If you are concerned about optimizing your code the most for speed, it would be a good idea to just call the flash based DriverLib APIs for smaller functions to allow the compiler to inline function calls.

    Best Regards,

  • in reply to Timothy Logan
    Expert 1420 points
    thanks for the responses guys.

    "The ROM code that you have in your driverlib.c file might differ in notation, however it should be binary compatible with the the code that you see in the individual peripheral source files."

    Famous last words. Has anyone actually compared the previous rom image against what the current code actually produces?

    I'm sure I'll figure all this out, but the current practices tend to introduce problems rather than reduce them. Not beating you guys up, trying to help.

    The driverlib is open source (BSD license). The way I would have dealt with this issue is a) first put the code (driverlib) in a git repository (github), b) when the ROM code was released to the sand folks to burn into the chip that is a release and I would have marked the repository accordingly.

    That would snapshot exactly what and how the driverlib got built for the ROM image and it is replicatable.

    then the new changes can get made and it would be explicitly clear as to what those changes are and what the exact state of the code is.


    Right now there are I don't know how many copies of all this source floating around. And there are various differences showing up in the files that should be same but aren't. Not only is it very confusing but its how bugs creep in.

    I was the 4th s/w engineer at cisco and we had to deal with this in spades as well. million+ lines of code.

**Attention** This is a public forum