• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 276 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C129XNCZAD: Using BGA rather than TQFP during COVID (supply chain issue) hoping to use one binary to support both processors

Greg Winters
Intellectual 720 points
Part Number: TM4C129XNCZAD

We use the TIVA129 processor for several of our boards (both TQFP and BGA versions).

For one of the boards that we NEEDed to build during COVID we could not source enough TQFP versions of the CPU for the build so we did a board spin and changed to the BGA package.

We plan to switch back to the TQFP once they become available again, but we will have one build of the board with the BGA version to support going forward.

If necessary we will create a separate version of the firmware designed just for this build, but would prefer to use a single binary that can run on either CPU.

CCS requires that you specify which processor you are using as part of the project properties.  I understand there will be a significant different configuration code depending on which CPU is installed.

Is it possible to:

1. Determine at time-zero prior to any configuration whether it is a TQFP or BGA version and branch to different code to configure based on this?

2. I know that which CPU you are using is a defined pre-processor constant and decisions are made within the libraries based on what to do at compile-time.  Is this going to prevent our attempt from working?

3. What other questions should I be asking?

Thanks

  • 0
    Guru 92251 points
    Greg Winters said:
    1. Determine at time-zero prior to any configuration whether it is a TQFP or BGA version and branch to different code to configure based on this?

    From a quick look at the datasheet, the Device Identification 1 (DID1) register contains a PINCOUNT field which should allow the package to be determined at run-time:

    Greg Winters said:
    2. I know that which CPU you are using is a defined pre-processor constant and decisions are made within the libraries based on what to do at compile-time.  Is this going to prevent our attempt from working?

    The TivaWare_C_Series-2.2.0.295/driverlib/ccs/Debug/driverlib.lib pre-compiled library is only compiled with one set of object files, which can be used on multiple Tiva devices. While a pre-processor constant is added to a CCS project for the specific part number when the CCS project is created, can't see that the pre-compiled library makes use of that.

    Greg Winters said:
    3. What other questions should I be asking?

    Do the different devices you are considering have the same amount of flash and SRAM?

    The CCS project does have a linker command file which specifies the flash and SRAM sizes, and so trying to use an executable on a device with smaller amounts of flash/SRAM wouldn't work.

    What are the full part numbers you are considering using for the firmware?

    If necessary, there are Peripheral Present registers in the System Control module which could at run-time be used to handle differences in the set of available peripherals in the device.

  • 0 in reply to Chester Gillon
    Intellectual 720 points

    We are replacing a TM4C1290NCPDT13R with a TM4C129XNCZAD13R.  Both have the same complement of Flash (1M) and SRAM (256K).  So we should be good to go there.

    I haven't been updating the TivaWare since what I had been using worked.  We are currently using TivaWare_C_Series-2.1.2.111 for all our boards.  Is there a good reason to update?

  • 0 in reply to Greg Winters
    Intellectual 720 points

    Also, whenever possible I use the built-in ROM routines on the chip.  I would assume this would work across those versions.

  • +1 in reply to Greg Winters
    TI__Guru**** 191486 points

    Hi Greg,

     Thanks to Chester. I hope he answered your question about using the DID1 register to determine the package. 

    Greg Winters said:
    I haven't been updating the TivaWare since what I had been using worked.  We are currently using TivaWare_C_Series-2.1.2.111 for all our boards.  Is there a good reason to update?

    The latest TivaWare version is 2.2.0.295 released in 2020. It fixes some bugs and added quite some examples for different modules. You don't have to upgrade to the latest version if the current version you have serves you well. However, I will still recommend you read the release note of the latest version to see if anything that you take advantage of. 

    Greg Winters said:
    Also, whenever possible I use the built-in ROM routines on the chip.  I would assume this would work across those versions.

    Yes, it will work across versions.