Hi,
I'm trying to develop and debug an NDK+BIOS application based on the MCSDK 2.0.17 image_processing demo. I'm powering on the EVM as "no boot" and loading the application using the mezzanine emulator. I am finding that with a "freshly powered" board it starts OK and can ping, communicate over sockets, etc. but if I do a 'system reset' on core 0 in the CCS debugger and reload the code, it doesn't work.
I have the same behaviour if I load the MCSDK "HUA" demo using the debugger. It works on power on, but after a reset it won't ping or respond to http requests, despite appearing to bring up the stack:
[C66xx_0] QMSS successfully initialized
[C66xx_0] CPPI successfully initialized
[C66xx_0] PA successfully initialized
[C66xx_0] HUA version 2.00.00.04
[C66xx_0] Setting hostname to tidemo-CE3530
[C66xx_0] MAC Address: 90-D7-EB-85-5B-14
[C66xx_0] EVM in StaticIP mode at 192.168.2.100
[C66xx_0] Set IP address of PC to 192.168.2.101
[C66xx_0] PASS successfully initialized
[C66xx_0] Ethernet subsystem successfully initialized
[C66xx_0] Ethernet eventId : 48 and vectId (Interrupt) : 7
[C66xx_0] Registration of the EMAC Successful, waiting for link up ..
[C66xx_0] Network Added: If-1:192.168.2.100
[C66xx_0] Service Status: THTTP : Enabled : : 000
This is very irritating, because you have to stop the debug session to power-cycle (or button-reset) the board seems to require restarting the CCS debug session.
I know I need the system reset between loading applications (http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/128857.aspx) because otherwise the EMAC registration fails. Is there any way to fix that? Can I add some additional hardware config code into my app that will allow it to cleanly restart in the debugger without a rest?
The other odd thing is that if I load hua using the debugger, it reports the system clock as 2000 MHz, when I expected 1000. That's really a separate question, why the EVM "quick start" guide (http://processors.wiki.ti.com/index.php/TMDXEVM6678L_EVM_Hardware_Setup) and the tech manual disagree about whether the DIP switches affect the PLL clock or not, but I have only managed to get consistent booting following the former. So my switch settings are all "on" except the first (=little endian) and the last (=DHCP off, because the post-beta NDK does not like my DHCP server, this seems to be a known bug as discussed on the forums).