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.

TM4C123GH6PM: Will Mixing Direct Register Access and Tivaware be Fixed?

Part Number: TM4C123GH6PM

Hello,

From time to time I need to mix the "direct register access" style of programming with Tivaware functions. Typically this is because I need some feature that is not included in Tivaware. For example, right now I want to explore the CAN controller on a TM4C123 launchpad by using loopback mode, while I wait for prototype hardware with CAN transceivers to arrive. As far as I can tell, CAN loopback cannot be enabled from Tivaware, so I need to do "direct register" access for this feature.

Contrary to what is advertised in the Tivaware documentation, combining the two models does not work very well: including the device-specific header (for example, tm4c123gh6pm.h) as needed to get the device register definitions causes numerous macro redefinition errors. Thus I either need to 1) copy-paste the register definitions into my own source files, or 2) I need to separate all of the "direct register access" code into a separate source file. Neither of these is really a "clean" solution. Option 1 is what I am doing currently, and it works, but I really shouldn't have to do it this way.

There has been some discussion of this problem in the past. In this thread, the issue is acknowledged, and it was said that TI is going to do something to fix it eventually. But that thread is more than a year old and the current version of Tivaware still has this problem. So I would like to ask, what plans does TI have to resolve this issue? Are we going to see a fix for it soon?

  • What code are you using?

    Mind you for this particular use, just having a separate module for loopback is not much of an imposition.

    Robert
  • I am modifying the simple_tx.c file found in SW-TM4C-2.1.4.178/examples/peripherals/can, which uses Tivaware / driverlib.

    Here are the modifications I made:

    // copied from tm4c123gh6pm.h:
    #define CAN0_TST_R              (*((volatile uint32_t *)0x40040014))
    #define CAN0_CTL_R              (*((volatile uint32_t *)0x40040000))
    
    
    // ... added to initialization code
    CAN0_CTL_R |= CAN_CTL_TEST;
    CAN0_TST_R |= CAN_TST_LBACK;

  • Have you tried the method outlined here (e2e.ti.com/.../381060 ) instead?

    Robert

  • Thanks for the suggestion. That method is a little better than either of the options I outlined above, although it seems needlessly verbose...

    In general I like Tivaware, but I can't understand why directly accessing a device register is treated like a special operation. I have not encountered any other firmware library where this is the case.
  • Oliver Douglas69 said:
    Thanks for the suggestion. That method is a little better than either of the options I outlined above, although it seems needlessly verbose...

    Quite welcome. Can't say as I'm enthused about the notation either. It does, however, have one advantage. Note that  since it uses the peripheral base any code developed for a single peripheral can be easily modified if it needs to support a different peripheral (while at the same time being more portable than a structure definition) by just making the base address a variable.

    Oliver Douglas69 said:
    I have not encountered any other firmware library where this is the case.

    You just haven't worked with enough libraries :)

    TIVAWare is the first library I've worked with that was actually usable.

    Robert

  • How can your post, "NOT be **LIKED**?" In depth support of your positions - historical context - a "linked example" - and humor - all seamlessly rolled together. (in other words - EVERYTHING that the recent, unwanted forum's (alleged) upgrade - was NOT!)