It seems the default method of flashing a out-of-the-box CC 9P9215 has changed since I last purchased them. Previously I simply connected a serial cable with hyper-terminal and turned it on. I then (rather quickly) had the chance to “press any key”, enter an ip address and FTP my image to the module. I just got a new bow of 110 modules and attempted to program them. I get a message:
“Starting TFTP recovery…”
This hangs for quite a while and then the message:
“Starting serial recovery”
Which also hangs for quite a while.
Followed by it spitting out “CCCCCC…”
I programmed one using the debugger to make sure I could at least do that, however it is time consuming an not good for production line.
What is the most expedient way to program a module?
Why did Digi change from the previous method,
which was not all that bad?
I am trying to get these 100+ units flashed today so a quick answer is greatly appreciated.
The symptoms that you are seeing is what I would expect if the unit had a corrupt application, but the bootlader was OK.
It sounds as if there has been a problem with the initial programming.
In theory they are recoverable if you have a TFTP server set up, there is some documents for this but I have never tried it, There is also a serial recovery, but again I have not tried it.
Out of setting up the above 2 options or using the debugger, I suspect the debugger will be quicker.
These are brand new out-of-the-box purchased directly from Digi International. There was never any application on them to get corrupted.
I simply plugged it into my mother board connected the serial cable and turn it on.
Granted the mother board is not set up the same as an eval board, but I did program twenty or so units this way with a previous pre-production build.
In theory they are recoverable if you have a TFTP server set up, there is some documents for this but I have never tried it, There is also a serial recovery, but again I have not tried it.
I’ve used both these methods with the ME9210, and they work. Obviously TFTP is faster!
The standard Digi bootloader forces a recovery, such as is described, if certain pins are at a particular level during startup. Have a look at customizeBootloader.c for the CC9P - looks as if gpio4 is the pin that matters in this case.
Possibly your hardware is triggering the download.
I’ve just encountered this problem on a fresh batch of CC9P.
Turned out that the RIA pin (GPIO4) was floating during boot, and reading as low. (On another board using the CC9P with the same circuit, its not been a problem!).
Possibly Digi’s code doesn’t enable the internal pullup before checking the level.