My RCM6700 projects using Dynamic C v10.72A take minutes to upload using the remote update scheme with the BU_USE_SECONDARY option. It takes about 2 minutes to download a 400KB file, and another minute to update. This seems rather long. I just noticed that during the entire process, lots of unreadable data is sent via serial port B. Does any know what this is? Since the serial transmission is very slow when compared to Ethernet, perhaps this is greatly slowing the process. Perhaps it can be turned-off somehow. Has anyone looked into this issue?
1 Like
Have you set the macros STDIO_DEBUG_SERIAL and STDIO_DEBUG_BAUD in your project/program? If so, all debug output goes over that serial port at that baud rate.
Or maybe you’re seeing the SPI traffic on serial port B where it’s writing the new firmware out to the serial boot flash? I think it shares that port with external pins, and that could be what you’re seeing.
It’s possible that you’re seeing 2 minutes of writing the 400KB to flash, and then another minute as it reads that data back to verify the checksum. If you enable verbose debugging output, that would slow down the process.
Are those times you’re seeing with the standard Samples/RemoteProgramUpdate/download_firmware.c sample, or with the update functionality included in your code?
STDIO_DEBUG_SERIAL and STDIO_DEBUG_BAUD were both in my program, and commenting them out had no affect on update time.
If the a SPI port is shared with serial port B, I suppose that could be what I am seeing. I am using SPI, but not via port B.
I have embedded the basic code from Samples/RemoteProgramUpdate/download_firmware.c into my program.
What I am seeing is a 2-minite download and then a 1-minute update time. I suppose the real question is whether or not those times are reasonable for a 400 KB program. Perhaps this is indeed reasonable, but it just seems very slow.
I assume you’ve enabled BU_TEMP_USE_SECONDARY, which means it will download directly to the alternate boot area of flash, and should be both fast and safe. You could define the macro BOARD_UPDATE_VERBOSE and watch your debug output to see what portion of execution is taking the longest.