Hi,
[quote]
We're also planning on being able to load in a new program at runtime, however our bootloader is not yet finished so I cannot test that. I was worried that this bug will appear then as well.
[/quote]
I am sure that, this problem wont occur if you are using bootloader(ARM UBL, If device is OMAPL138) (bootloader should do the gel file job)
[quote]
The system reset mentioned in the first post was an error, it was supposed to be reloading the program.
[/quote]
Now, I understood your problem,
I have also faced this unexpected behaviors from some of the projects(In your case is USB) when you are reloading program,
Starterware code will doing the low level initialization, some of the variables is not getting cleared when you are reloading/loading program without quitting the CCS,
1) You can disconnect the target(DSP CPU) and connect again then try to load the DSP USB program.
Because, When you are doing disconnect/connecting the target(DSP) again, the gel will initialize the all peripherals including USB,
2)
Anyway, CCS tool is used for debugging purposes and CCS won't be used for product release, So better to use ARM UBL code to wakup the DSP and call DSP program through entry point.(through flashing those ARM UBL and DSP app in SPI/NAND/NOR flash media)
http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138#Booting_DSP_Binaries
http://processors.wiki.ti.com/index.php/OMAPL138_StarterWare_Booting_And_Flashing
I'm doing some experiments for this and ll update,