I’m working on an application for the ConnectCore 7U under Net+OS 7.1.10 (just got it yesterday, was using Net+OS7.0 and pre-releases of 7.1 before that).
I don’t know if my problem is specific to CC7U, or if other models do it too. I haven’t reinstalled Net+OS 7.0 (yet) to see if it did it there.
To facilitate firmware updates if they would ever be necessary, I chose for a network boot scenario: only rom.bin is programmed to flash, at each boot it will get the boot server and filename as DHCP options, use TFTP to download the actual firmware to RAM and start it without ever writing it to flash (this functionality is provided in the standard rom.bin, just set option “WriteToFlash” to “No” in bootldr.dat).
This works perfectly as long as there’s only one module, but now that I’m doing further tests with multiple modules connected, a huge problem turns up: rom.bin ignores the MAC address that’s present in NVRAM (in a CC7U that’s EEPROM over I2C), it always uses the default address that’s set in appconf.h.
The module actually requests an IP address twice each time it starts: first rom.bin does it with the default MAC, it downloads the application image and starts it, and then that image requests a new IP address using the correct MAC address.
Booting two modules at the same time just doesnt’work (except for the very first time I tried it, a lucky streak made it slip through then).
When you examine blmain.c you can see that the boot loader (i.e. rom.bin) tries to get the MAC address from EEPROM (calls NANVInit to initialize the ‘NVRAM’, then calls customizeGetMACAddress to read the MAC address), but for some reason this doesn’t work.
I reported this to Digi through my normal contact (which is a redistributor) yesterday, but so far I’ve had no response.
I’ve just confirmed an order of 4500 modules (time is pressing, so after testing it with a single prototype I didn’t wait for more test results), and I’d hate to have to compile a separate rom.bin with a fresh default MAC address for each one.
Anyone with a solution, or with more insight in the boot process than I have?