View Full Version : Question for zorlac or sdeens or whoever has any clues or comments concerning 430/1s
Do a search for RGA430. There are a bunch of threads regarding this issue, including one about 350 post's long. Skinerds method for write protecting combined with the latest tsop image from the downloads seems to have cured the problem for most around here. Skinerd has even taken the time to post photo's and everything.
zorlac
04-13-2004, 09:36 PM
I'm having a hard time reading between the lines here. What problems/oddity are you referring to?
I usually don't pay that much attention to the existing version before I jTAG them, but I did notice a couple on Friday that were last upgraded in Feb.
BTW, the software TSOP lock will not work. I'll use the DRD430 with an M28 chip as an example - all 71 sectors are locked from the factory and must be unlocked one-by-one, or quick erased by manually giving the chip 12v on the right pin. In order for it to upgrade itself from the stream, the update routine must have the capability to unlock the sectors first.
The only way to prevent the update is to change the version to the highest number possible or physically lock it by tying write enable to ground and cutting the trace from the CPU. The former method is not 100% tested and may subject you to hashing, however. The latter method may cause nag messages when a new upgrade is in the stream.
skinerd
04-14-2004, 01:05 AM
I'm having a hard time reading between the lines here. What problems/oddity are you referring to?
I usually don't pay that much attention to the existing version before I jTAG them, but I did notice a couple on Friday that were last upgraded in Feb.
BTW, the software TSOP lock will not work. I'll use the DRD430 with an M28 chip as an example - all 71 sectors are locked from the factory and must be unlocked one-by-one, or quick erased by manually giving the chip 12v on the right pin. In order for it to upgrade itself from the stream, the update routine must have the capability to unlock the sectors first.
The only way to prevent the update is to change the version to the highest number possible or physically lock it by tying write enable to ground and cutting the trace from the CPU. The former method is not 100% tested and may subject you to hashing, however. The latter method may cause nag messages when a new upgrade is in the stream.
The flash protect does work for the Intel and the STM28W, you might get nags, but it won't update.
The STM29W will write protect, but it won't erase protect by using the trace cut and grounding normally done, so an update attempt erases part of the flash resulting in a dead receiver.
skinerd
04-14-2004, 04:50 PM
The IRDs "updated" just fine as far as excepting the new "update" again actually as they had already accepted the Feb 14 update and then got "updated" again theis time still bing at the new revision of firmware and fully functional but they can no longer be reflashed through the JTAG port by the conventional means as the DCU will no longer invoke upon boot from BFR mode or function 0 and appear to go directly to regular ROM boot or mode 1 or whatever no matter what the state of the logic level on the BFR pad. The entire IRD flash took the update and removed the NO_ZKT patch from the firmware and resetting the entire firmware back to stock. I do acknowledge that evidently I did not have the TSSOP WE properly disabled but this appears to be a non-issue now as the IRD will not be "reflashable" insitu by JTAG anymore UNLESS BFR can be re-asserted. If your "supposed" flash lock were the only problem I would merely have to pull the WE HIGH AGAIN AND REFLASH but as the DCU never configures correctly for access - these IRDs are pretty much rendered unmodifiable. I need to check the I/O level state of the bootlink mode 1 pin and the bootlink mode 0 pin inputs to see if they perhaps are in conflict. I was mainly just asking if anyone had noticed that their IRDs might not be flashable anymore EVEN if they are still functioning with the firmware mod? I have a potential backup method using a serial bootloader routine intialized and ran through the low speed serial dataport.
It would be nice if some other testers would check to see if their BFR toggle is still functional or not and I wonder if any 435s have been affected as well if this is a real problem. Thanks for responding guys and if you have any other information or potential solutions to counter or reveal the source of the problem. Give me shout back here.
I don't know where you got all that, but absolutely untrue......
I have modded a few thay had the update, no problems what so ever....
zorlac
04-15-2004, 12:15 AM
Sounds like you are actually having problems with your jTag device. Let me explain:
I've done probably hundreds of receivers without any significant problems. One day I had a DRD435 that I was going to throw out the window because I could not get the jTag to work with it - DCU; poke; wrong flash; you name it. I decided to set it aside and come back to it later.
I probably did another 10-15 without any problems, so I decided to go back to it. Same problem. I searched around the forums to see if anyone was having the same problem and tried a couple of suggestions:
Shorter wire length; Load jKeys within 2 seconds of turning on the IRD; etc...
Finally, I just built another jTag from a different schematic I found and the problem was solved. I still had to fight with it, but it was a lot easier. I've since sold that damn thing to a guy in Mexico. Good riddance!
The only real difference from the new jTag I built and my old one is board layout and the buffer chip. When I built my first one from Unwink's diagram, I had two smaller buffer chips laying around instead of the bigger one that was required. I just modified his schematic so I could use two chips. The buffers have the same data sheet, though.
Keep messing with it, I bet you'll get it.
zorlac
04-15-2004, 12:18 AM
I forgot to add that I highly doubt if there is a way to affect DCU or BFR with specific programming in the flash. From the way I understand it, those are features that are HARD CODED into the CPU itself and do not rely on external influence.
Someone please correct me if I understand that wrong.
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.