O Canada! > Canadian > TekSavvy > Upgrading Firmware on Thompson DCM475

reply to mlord

Re: Upgrading Firmware on Thompson DCM475

The test setup.. forgot to disconnect the Logic Analyzer

reply to mlord

SPI activity

reply to Teddy Boom

quote:

---

5V is on the edge really.. If it is really 4.8V, then I'm sure it is pretty safe (though I'd like to keep it 4V and lower normally). If it is really 5.5V I think you are risking the modem..

---

Mmm.. interesting. You know how these modems always chop off the log messages displayed in the web interface? Well.. the full log messages (not chopped) are stored near the end of flash.

I've been meaning to get one of these for a while.

»www.adafruit.com/products/757

Conversion from 3.3 to 5v or the other way around is way too common.
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )

Yeah, that's the same type of gizmo I'm using here, except mine is from SparkFun: »www.sparkfun.com/products/8745
Edit: But I like the one you posted the link for even better. Gotta get some!

Handy little sucker. I'm actually using the "LV" (Low Voltage) side to POWER the flash chip in-circuit inside the modem. Works rather well!

After disconnecting the logic analyzer, the loading on the pins is now low enough that I'm getting very consistent error-free dumps every time. Takes just under 19 minutes to dump all of flash in ASCII-hex (with spaces) over the serial link. I can speed that up by eliminating the spaces between byte values, which ought reduce the time by 1/3 or so.

At this point, I'm just about ready to borrow a modem with 02.16 firmware to read the image out of.

Cheers

reply to mlord

Six minutes and thirty-seven seconds to rip and transfer the 4MBytes of flash, using a 1Mhz SPI clock. That's good, I suppose. Programming will be slower.

Speaking of which, I can't just shove the entire image from another modem into this one, or can I? Surely there's an area in flash that records the MAC addresses for the modem? I do see the MAC address in several places, in both binary and formatted ASCII.

Teddy Boom?

Okay, there are several distinct regions within the 4MBytes of flash.

The first 64KB appears to be a fixed "bootloader" area, including MAC address and various crypto certificates.

The area from 0x010000 to 0x1fffff (2MB less 64KB in size) is likely the "factory image" area. This consists of a firmware code image, plus padding. The odd thing is, there's a bunch of "junk" in the first few 64KB blocks following the "used portion" of the image here, possibly leftovers from an earlier/larger "manufacturing/test image" at the factory. The "regular" image padding appears to be 16KB blocks of 0xffffffff, except with the first 32-bits of each 16KB block zeroed out 0x00000000.

The area from 0x200000 to 0x3effff (same size as above) looks like the "secondary image" area, used for new firmware downloads in the field. The suspicion is that if a valid image is found here, then the booloader uses it rather than the "factory" image. Currently on my modem, it's a duplicate of the factory image, minus the "junk", with "regular" padding as described above.

It's not clear if field upgrades alternate between the two images, or always go only to the second image. I can probably find out with some experimentation once I have the 02.16 image to play with alongside the 02.08 image.

The final 64KB of flash is mainly used as a set (two sets?) of log buffers.

Since none of the flash has been write-protected, it's easy to do all kinds of experimentation without having to lift the WE (Write Enable) pin.

Time to start erasing/programming things now.

Is Rogers the only company refusing to upgrade firmware? How about Videotron? Are they holding the same deplorable attitude and practice?

Dunno. But for most modems, we can now do it ourselves, or take/send it to Toronto to have it done. I'll be offering updates to DCM-475 modems here in Ottawa shortly.

Cheers

reply to vientito1

Please give out sites where we could find info about DIY flashing of most brands we find on market. I have googled but failed to get any useful info so far.

reply to vientito1

reply to vientito1

reply to mlord

Workaround now implemented, doing some dry-runs with it now: transfering data, and pretending to erase/program without actually doing it.

Edit: 15 minutes and 6 seconds to transfer the data, without programming the flash for real./edit

Slow. Might take 20 minutes to program the 2MB- file. That's not horrendous, though I was hoping to do it in under 10 minutes. Bedtime now. I'll continue this after work on Friday.

Cheers

Edit: For the curious, the receive buffer seems to overflow after 63-64 bytes on this Arduino board. So, I'm sending the page (256 bytes) data as a series of buffer-fill commands, with each command line never longer than 62 bytes. The Arduino sends back an ack to the host after receipt of each buffer-fill, and the host waits for the ack before sending the next one. After all 256 bytes have been buffered, the host then sends a "program page" command to the Arduino. I could get rid of that last step with some optimization, but it's in there for now.

The 63-64 byte limit likely comes from the USB packet size of 64 bytes for a "full speed" connection like this one. Unnecessary, but due to an Arduino bug that's the limit.