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.

Best way to implement configuration data

Other Parts Discussed in Thread: UNIFLASH

Our product under development will require a level of configuration for each client. The configuration extends to numerous timer thresholds, drive frequencies for PWM IO, GIO control options etc. At present it trivial for us to set up the configuration parameters in a header file and flash the re-configured software each time. For production I do not want to rebuild the software (or rather the entire application) each time. I would prefer to use something similar to the CCP methods of Automotive for configuration data in RAM that is the flashed by a driver on command. But, that is overly complex for this product so the options i'm considering are as follows

1. reserve a Flash sector purely for calibration/configuration data

> is it possible to use the CCS scripting and the uniflash tool to flash only this section with a custom configuration/end of line application? Are there any good references online to pulling together the scripting of CCS to compile a flashable section using uniFlash?

2. use CCS scripting to 'poke' specific global variables with our product held in a configuration state over JTAG, that would then use the FEE driver to store that data to bank 7

Any advice and pointers to useful forum posts etc in the area would be appreciated.

Jamie

  • Hi Jamie,

    One other possible solution you left out is the use of the Customer OTP. This thread discusses a similar use case; although, the data to be stored is manufacturing data. e2e.ti.com/.../342645

    The question on this option is if it would provide enough space to store all the data you need to store.

    As far as the other options. There is the possibility to use Uniflash with scripting since Uniflash also has a command line interface but I don't have a lot of information on it at the moment. Theoretically, you should be able to just program a single sector without disturbing any other parts of the flash. You would have to provide the data as a Uniflash compatible file format such as Intel Hex, coff format, or a simple binary.

    Another solution would be to have something similar to a boot loader. When the device is stimulated in a certain way it enters this calibration programming mode. You could then use one of the available communication methods such as UART, SPI, or CAN to dump data to the algorithm that would then program a special reserved sector, customer OTP, or bank7 emulated EEPROM. The application would need to utilize the Flash API to do the programming. This is similar to how it was/is done in the auto industry via CAN.
  • Thanks Chuck,

    The OTP is an option but the 'one time' nature of it moved me to consider something more automotive like.

    I've just been reading around the DSS capabilities and I think my path forward is to use some simple DSS scripting to

    1. connect the target,
    2. force a flag that pushes my application to a configuration state,
    3. force the value of the global configuration data variables
    4. read back and verify the values
    5. force the FEE write and then leave the unit in a locked state requiring powercycle

    The FEE data would then be used to intialize the configuration data on powerup. This will be the easiest approach and can then use a simple test file for reading in the customer specific parameters. Also opens the door to a wealth of programming frameworks for a GUI based End Of Line configuration tool.

    I'll keep this thread open until I verify my approach.
  • Thanks Jamie. This sounds like an interesting approach. I hope that you can share more of your implementation details and results when you follow up with us. It's always interesting to hear about real solutions for real world problems and it may help someone else along the way!