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:
- Configure (initialize) Memory
- Configure the GPIO ports (especially PF0_GPIO32 and PF1_GPIO33)
- Signal the C28xx bootloader to let the C28xx run
- Wait (infinitely) for the C28 to signal that it is running
- Configure the EMAC
- Send a text string over Ethernet to a waiting server
- Wait infinitely ("while (1);")
The code on the C28xx side looks roughly like this:
- Configure (initialize) Memory
- Signal the ARM core that the C28xx is running
- Configure GPIO for I2C
- Send an I2C command to turn on an LED
- 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:
- I load both apps onto Flash (both ARM and C28xx code).
- I run the ARM code until it gets to the infinite wait in step 4, then I pause execution
- I begin execution on the C28xx core
- 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!