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.

RTOS/F28M36P63C2: C28xx: I2C works under debugger but not stand-alone?

Part Number: F28M36P63C2

Tool/software: TI-RTOS

On my board, PF0_GPIO32 is routed for I2C SDA and PF1_GPIO33 is routed for I2C SCL. 

The code on the ARM side looks roughly like this:

  1. Configure (initialize) Memory
  2. Configure the GPIO ports (especially PF0_GPIO32 and PF1_GPIO33)
  3. Signal the C28xx bootloader to let the C28xx run
  4. Wait (infinitely) for the C28 to signal that it is running
  5. Configure the EMAC
  6. Send a text string over Ethernet to a waiting server
  7. Wait infinitely ("while (1);")

The code on the C28xx side looks roughly like this:

  1. Configure (initialize) Memory
  2. Signal the ARM core that the C28xx is running
  3. Configure GPIO for I2C
  4. Send an I2C command to turn on an LED
  5. Wait infinitely ("while (1);")

This works reasonably well in the debugger.  Of course, I have to do a little dance to get the two cores to run in the right order:

  1. I load both apps onto Flash (both ARM and C28xx code).
  2. I run the ARM code until it gets to the infinite wait in step 4, then I pause execution
  3. I begin execution on the C28xx core
  4. I bypass the infinite wait code in step 4 (ARM code) and let the ARM core run

This process lets me see the text string at my server (from the ARM core, step 6) and also the LED lit (from the C28xx core, step 4).

Unfortunately, if I exit the debugger and power-cycle the board, I get a different behavior: I get the text string at my server (from the ARM core, step 6), but I do not see an LED lit.  So it seems that the debugger is changing the behavior (or providing some unexpected configuration) of the I2C GPIOs. 

Is there a sample program for I2C on the C28xx?  I didn't see one.  Failing that, how can I figure out what the debugger is doing (or perhaps -- somehow -- disable whatever the GEL file is doing)?

Thanks!

  • I figured out how to configure a GPIO to output an 8-bit value (serially).  My C28x main() starts like this:

    int main(void)
    {
        DGPIO(MAIN_ENTER); // GPIO debug: start of main()
        InitRAM();
    
        DGPIO(MAIN_COPY);  // GPIO debug: before memcpy()
        memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);
        DGPIO(MAIN_COPY2); // GPIO debug: after memcpy

    I build and flash this code, then run it outside the debugger and watch the GPIO pin with an oscilloscope.  On the O-scope I see the MAIN_ENTER and MAIN_COPY codes on the GPIO pin, but I do not see the MAIN_COPY2 code.  Here is the text from the linker script file that defines RamfuncsRunStart (et al):

        GROUP
        {
            ramfuncs
            {
            	-l F021_API_C28x_FPU32.lib
            }
    
        }	LOAD = FLASH PAGE = 0,
    		RUN = L0_S4_RAM PAGE = 1,
    		LOAD_START(_RamfuncsLoadStart),
    		LOAD_SIZE(_RamfuncsLoadSize),
    		LOAD_END(_RamfuncsLoadEnd),
    		RUN_START(_RamfuncsRunStart)
     		RUN_SIZE(_RamfuncsRunSize),
     		RUN_END(_RamfuncsRunEnd)
    

    The FLASH page is defined in PAGE 0 as:
    FLASH        : origin = 0x00130000, length = 0x0000FFF0 // BOOTLOADER FLASH

    The L0_S4_RAM block is defined in PAGE 1 as:
    L0_S4_RAM    : origin = 0x00008000, length = 0x00009000 // on-chip RAM block L0-L3, S0-S4

    Before the C28x core is signaled to load its code from flash, the ARM core assigns Shared Memory blocks S0-S4 to the C28x.

    Any hints on what I might be doing wrong here?

  • Steve,

    1) Is S0-S4 RAM assignment to C28x done before the DGPIO(MAIN_COPY)? Do you block C28x from executing further until M3 indicates that the assignment is done?
    2) What all do you have in ramfuncs?
    3) Do you have an NMI ISR on C28x? Can you try toggling a GPIO in the ISR to see if you are getting an NMI?

    Thanks and regards,
    Vamsi
  • Steve,

    Do you have any update on this debug?

    Thanks and regards,
    Vamsi
  • Steve,

    Did you try toggling a GPIO in the C28x NMI ISR to know if an NMI is occuring?
    If your issue is solved, please update the thread with the details for the benefit of others.

    Thanks and regards,
    Vamsi
  • Steve,

    I am closing this thread since I did not get a response in the last 3 weeks.

    Thanks and regards,
    Vamsi