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.

interrupt won't trigger when code is running in flash memory TMS470MF06607

Other Parts Discussed in Thread: HALCOGEN, UNIFLASH, TMS470MF06607, TMS5700432

Hello,

This is my first time posting to a forum. I'm currently working on the Battery Management System of an electric motor vehicle and we need to program the code in the flash so we can reset it when we need to and run the code without having to plug it into a computer.

When I program the the code in release with the debug probe of the FTDI of the board (which we designed), everything works fine. As soon as I take the debug probe off and the code is still running, no interrupts are seen by the micro controller, while the program still runs. Even if I cycle the power and hit the reset button on the board, the interrupts are still not seen by the micro controller. I have tried loading the interrupt function in the flash, and copying it to the ram on the main start-up, but still nothing. 

 Here is the section portion of the sys_link.cmd file 

SECTIONS
{
    .intvecs : {} > VECTORS
    .text    : {} > FLASH0 | FLASH1  //code
    .const   : {} > FLASH0 | FLASH1	 //constant data
    .cinit   : {} > FLASH0 | FLASH1  //initialization tables
    .pinit   : {} > FLASH0 | FLASH1  //

    .bss     : {} > RAM	 //global and static vars

    ramfuncs : LOAD = FLASH0,
    		   RUN  = RAM,
    		   LOAD_START(__RamfuncsLoadStart),
               LOAD_END(__RamfuncsLoadEnd),
               RUN_START(__RamfuncsRunStart)

    .data    : {} > RAM     		 //
    .sysmem  : {} > RAM				// DYNAMIC MEMORY ALLOCATION AREA

    .stack   :                            /* SOFTWARE SYSTEM STACK                 */
   {                                                   /* initial stack pointer values          */
    . += 0x00000400;  _Stack_Table_Pointer  = .;
    . += 0x00000400;  _Stack_Handler_Pointer  = .;
   } > STACKS

}

Here is the start of my main function

extern unsigned long __RamfuncsLoadStart;
extern unsigned long __RamfuncsLoadEnd;
extern unsigned long __RamfuncsRunStart;

#pragma CODE_SECTION(canTransmit,"ramfuncs")
#pragma CODE_SECTION(spiTransmitDataBQ,"ramfuncs")
#pragma CODE_SECTION(spiReceiveDataBq,"ramfuncs")
#pragma CODE_SECTION(spiReceiveDataCURRENT,"ramfuncs")
#pragma CODE_SECTION(gioHighLevelInterrupt,"ramfuncs")
#pragma CODE_SECTION(gioLowLevelInterrupt,"ramfuncs")
#pragma CODE_SECTION(gioNotification,"ramfuncs")



void main(void)
{


 // fonctions d'init vont ici! mets les tous

	long qw;
	for(qw=0;qw<10000000;qw++);

	CopyRamFuncs();

//...A lot of more code goes here...
}

 There is a lot of info on how to program to the flash memory for standalone programs on the TMS320, but not a whole lot on the TMS470M, so my question is the following. How do I send the code properly to the flash, including the interrupts?

Thank-you in advance.

  • Hi Tristan,

    It seems you are already programming your code into flash since your main is copying the code into RAM for execution. Correct?

    None the less, I am not sure what your question is. CCS6.1 is the latest IDE from TI and it supports the TMS470M devices for code development, build, debug, and flash programming.

    Also, it isn't clear if you are using HALCoGen or not, but this is another helpful tool to help setup your startup and driver code. It supports several IDEs including IAR and TIs CCS.

    If you are looking for a stand alone programming tool, TI's Uniflash is the latest and best option for stand alone programming. Other solutions are available for production programming but I don't think this is what you are looking for.

    The interrupt vectors are usually located at the beginning of Flash memory (0x0 to 0x40) and vector code execution to your ISR upon being triggered via the VIM.

    Finally, note that there are no similarities between the TMS320 and the TMS470M other than similar nomenclature. The flash technology as well as the overall chip architecture is completely different so care should be taken to review the Datasheet and the TRM.

    One last question, although the TMS470MF06607, is capable of performing the tasks that you are looking implement in a Battery Management system, is there a specific reason you are using the TMS470M? The thought behind my question is that the TMS470M, although automotive qualified with limited safety content, is limited to a safety classification of QM (Quality Managed) and does not have a ASIL rating as would normally be required in automotive projects.

    If possible, I would recommend having a look at the TMS5700432 device which is an ASIL D device with similar but expanded features. It is available on a Launchpad for a very reasonable cost (approx. $20.00 US).

    You can have a look here: www.ti.com/.../launchxl-tms57004
  • Thank-you for your quick response Mr. Davenport. 

    We chose this chip as it had a cheaper evaluation board (senior year engineering project) so we could develop code on it. We then made our own board with the TMS470M. we are using the BQ76PL to monitor the battery cell voltages. I used HalCoGen to generate the skeleton of the code at the very beginning (a few months ago). Everything is pretty much programmed to the flash except for the .bss ,data and .sysmem. Uniflash does not support the TMS470MF0667 so I can't flash it with that. 

    The whole system/code works perfectly while the usb/jtag is connected to the micro controller, but as soon as I pull it out, sections of the code stops working, more precisely the interrupts coded in the TMS470M. Is there something else I need to add, a certain #pragma to put the interrupts in the flash? 

    Thank you in advance.

  • To add more information, it's as if the jtag tries to take code off of the micro controller when it gets unplugged...
  • Hi Tristan,

    Which interrupts are you using? RTI, GIO, SPI,... ? If you are only using GIO interrupts, there is a feature that was implemented to disable the input buffers dependent on the state of the PULLSEL and PULLDIS configurations for a given pin. This feature is disabled during debug but could impact operation when not connected to the debugger. Effectively, the CPU would not see the inputs on the pins and no interrupt would fire. See table 19-4 in the TRM SPNU495C.