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.

EK-TM4C1294XL: ROM_SysCtlClockFreqSet(..) is not defined in driverlib/rom.h file of TIVAWARE 2.1.2.156 rom.h

Part Number: EK-TM4C1294XL

Hello.

I tried to compile the ROM_SysCtlClockFreqSet(..) command using the TIVAWARE 2.1.2.156 rom.h from the driverlib/ area but compiler issued an error to this definition.

I checked into the file rom.h and as you can verify the  needed #define ROM_SysCtlClockFreqSet((uint32_t (*)(uint32_t ui32Config, uint32_t ui32SysClock))ROM_SYSCTLTABLE[48])  does not exist.

Is it O.K. if I just add in this file a definition like 

#if defined(TARGET_IS_TM4C129_RA0) || defined(TARGET_IS_TM4C129_RA1) || defined(TARGET_IS_TM4C129_RA2)

       #define ROM_SysCtlClockFreqSet((uint32_t (*)(uint32_t ui32Config, uint32_t ui32SysClock))ROM_SYSCTLTABLE[48])

#endif

Thank you,

John

  • Hi John,
    No, you can not do that. Whatever that is mapped to ROM_SYSCTLTABLE[48] is deprecated. I don't even know what function pointer is at ROM_SYSCTLTABLE[48]. How did come across to use ROM_SYSCTLTABLE[48]? At one point of time there might be a ROM_ version of the SysCtlClockFreqSet but it was removed for a reason most likely due to bugs and hence the reason it was removed. Please use MAP_SysCtlClockFreqSet() instead as this is the safest way to ensure you are using the correct driver API. If the ROM version is not found the MAP version will automatically resolve to just SysCtlClockFreqSet().
  • Understood
    Thank you very much Charles.
    John
  • Charles, the TIVA C Series TM4C129x ROM USER'S GUIDE (SPMU363) doc, clearly declares in page 461 - 17.2.1.2 that this ROM function is O.K. to use. Is there any newer doc of ROM USER'S GUIDE? Thanks. John
  • Hi John,
    I just read it and still saw ROM_SysCtlClockFreqSet(). You are correct that it is mapped to ROM_SYSCTLTABLE[48]. The ROM user guide was last updated on May 2014. It may not be as up to date as the latest TivaWare release on the support for ROM_SysCtlClockFreqSet(). I will go with the TivaWare release. This is the reason why we recommend using MAP_ for better portability.
  • Hello Charles. The ROM function it is indeed depreciated. Inside the bl_emac.c flash file of the 2.1.3.156 version of the Tiva Firmware Development Package, although this ROM function is of clearly defined use, the text before it suggests otherwise unless one correctly fine tunes the needed register. It is almost always the case that unforeseen uses of available functionalities may end up in mess. I would suggest to the designers of TI's Cortex-M or other processors, to save two pins on each IC design, so that when these two jumpered by the firmware developers to allow under a certain procedure ROM to be updated. It may already be the case that some undocumented feature of Cortex-M4 family may allow for such a treatment of the chips, although this may be only for internal TI's use. I don't know... Anyway, thank you very much for all the help so far. John
  • Hi John,

    I didn't quite understand what you meant to have two jumper pins to allow for ROM update. The update the ROM it requires a reticle (aka mask) change on the contact level. It is a silicon change, that is what I mean. However, I'd like apologize the inconsistent document that might have confused you.
  • Hi Charles. Just a suggestion was, nothing important indeed. I was just thinking of a possible software tool like LM Flash programmer and a hardware driving method, let's say two special chip's pins that when jumpered would allow ROM area to be reprogrammed. Kind of BIOS upgrade. Anyway, thanks a-lot. John
  • Hi John,
    No problem. Thanks for the suggestion though.
  • Hello Charles. By the way, in page 168 of the TivaWare Utilities Library 2.1.3.156, in the programming example of the "Ethernet Software Update Module", the call of the SoftwareUpdateBegin(.......) function seems to be wrong since the parameter (ui32SysClock) is missing. Thank you. John
  • Hi John,
    I just saw it too. Thanks for reporting. I'm not sure if and when will be another update to the documents though.
  • Charles I would need your help on the following bootloading scenario:
    a) The ethernet flash bootloading method as described by Texas at github.com/.../boot_demo_flash.c ,seems to operate but it is not obvious to me for how much the bootloader will wait before giving control to the existing main firmware application starting @ 0x4000 if no bootloading is happening.
    b) Suppose now that my application receives a particular message from the TCPSERVER that runs as part of my main application. Say "START_BOOTLOAD". Then my application writes an "1" at a specific EEPROM location and reboot my board.
    c) A minor modification in the code at a) is that the code at startup reads that specific EEPROM location and if finds it "1" makes it '0' and then waits for ever for receiving firmware data and so I can start sending the new bin file over ethernet. If finds a '0' at the EEPROM location then just pass control to the main application at 0x4000.
    QUESTION 1: Can this scenario work?
    QUESTION 2: If I have assign a specific internal IP, port, subnet and gateway to my board inside the bootloading routine and have configure NAT to my router, can I perform this update over internet?
    QUESTION3: Can I use LM FLASH Programmer or other tool, or any trivial TFTP client that I have code for sending the bin to the remote board?
    (If it is my TFTP client I know that I have to send the magic-packet, or I can bypass this procedure provided that I also modify code at a) for not checking for magic packet before goes to void JumpToBootLoader(void) routine? )
    Thank you very much,
    John