So Over the last month of so I have been working on devising methods of recovering bricked prizms. Here shall be my current status and information gathered.

Possible plans of attack Ordered by most looked into

In Circuit reflash of the external flash chip.

Benefits:
Dirty and cheap requires minimal invasive soldering and is useable as a permanent fail safe for any flash memory based corruption.

Cons:
Over 50 points need to be soldered
Other items on the address bus may try to interfere.
Installation may not be 100% stable due to above 50pts of solder needed.

Progress.
Flash chip has been fully mapped out pin wise to corresponding pads and vias.
Color coded pictures of this can be found here
http://img.keepdream.in/prizm/ (Excuse my paint skillz)
Identification of Reset/CE pins for other devices on data bus is sadly lacking. The Cpu system is hopefully reset by the major reset circuit. The second smaller epoxy blob remains un-identified and is a possible interference. If it is ram the Chip enable pin or reset pin must be located.


In Circuit Debugger. U-HDI
This one is mostly speculation and currently the only other "software" idea I have. The documentation for similar SH4 processors talk of a jtag debugging interface that could be used to force load the cpu information we want. Would also be useful for prizm dev. Nothing more is known about this. Yay theory.

Flash replacement...:
Self explanatory. Easily Doable. Just expensive Sad

FPGA/SecondMem in circuit highjack:
A Very easy to execute idea. It Expands on the In Circuit programming idea to add a second Flash Chip into the circuit on the same Bus line as the old chip, Allowing is to flash a good known software to that then load that onto the old flash chip via trickery.


Shy of that I am looking for help i do not have the resources to locate the information I need to ensure a safe in circuit flash of the FlashMem. Shy of using an fpga to emulate some things and emulate a flash chip. I am out of other ideas.
OK, so here are some thoughts on each "plan of attack".

In-circuit chip reflashing IMO is not the easiest method, due to the giant mess of tiny cables and lots of solder points, but it's the one we can effectively start trying, as U-HDI is still nowhere to be seen. I have very little experience in electronics, anyway here's a suggestion: in order to reduce the probability of items in the address bus interfering, try to power the chip externally. Otherwise, if you power on the whole Prizm, you'll have the CPU also trying to access flash (to execute whatever might be there) which I don't think is a good idea.

U-HDI would be the nicest option, but sadly there's no information, as you say. Finding out how to use it would actually help with much more than just unbricking Prizms... it's actually possible the pins are exposed in the PCB just like the flash ones, but with so many traces going out of the CPU, it's not going to be easy. (And unfortunately, Casio doesn't seem to leak schematics and the like often, at least when it comes to calcs.)

"Flash replacement"... wouldn't you still need to program the replacement flash (and still have the difficult task of desoldering the existing one, then soldering the new one)?

Circuit hijacking with a second memory... this has all the potential problems of connecting to the chip with it in the PCB, plus some more ones, so I can only see this as something to be thought about if in-circuit reflashing is done successfully?

geekboy1011 wrote:
ensure a safe in circuit flash of the FlashMem.

Talking only about reading the current flash contents and not "fixing" them, what's the worst that could happen? If you don't turn on the CPU and don't enable the WE#, what I see as the worst that can happen is not being able issue proper commands to the flash (which, I think, can only cause issues that will go away after power-cycling the chip?), or not being able to receive data back. If you must power the whole Prizm and in turn the CPU, and assuming the first sector is erased, it will be full of 0xFF. The first thing the CPU will execute is 0xFF which AFAIK is not a valid SH4 instruction; what does the CPU do in case of invalid opcodes? I suppose it will go to the exception handler (which, judging by http://prizm.cemetech.net/index.php/Error_handling#Exception_Types, is blanked out as well...), and then halt?
We'd only proceed to writing if reading is stable. And even if then writing failed, well, the Prizm is bricked already, and more likely than not, the chip would be in a state where it could be rewritten again with other methods, if necessary. Am I missing some big problem with just going ahead and connecting the microcontroller to the flash pins?
gbl08ma wrote:
OK, so here are some thoughts on each "plan of attack".
Circuit hijacking with a second memory... this has all the potential problems of connecting to the chip with it in the PCB, plus some more ones, so I can only see this as something to be thought about if in-circuit reflashing is done successfully?

This is actually easier. Todo this you have to just solder the connections for the chip on the old board and hold the reset line on the old flash chip low. Badabing done.

The problem with is is its a lot of solder work and board design But is currently the easiest plan of attack.

Quote:

Talking only about reading the current flash contents and not "fixing" them, what's the worst that could happen? If you don't turn on the CPU and don't enable the WE#, what I see as the worst that can happen is not being able issue proper commands to the flash (which, I think, can only cause issues that will go away after power-cycling the chip?), or not being able to receive data back. If you must power the whole Prizm and in turn the CPU, and assuming the first sector is erased, it will be full of 0xFF. The first thing the CPU will execute is 0xFF which AFAIK is not a valid SH4 instruction; what does the CPU do in case of invalid opcodes? I suppose it will go to the exception handler (which, judging by http://prizm.cemetech.net/index.php/Error_handling#Exception_Types, is blanked out as well...), and then halt?
We'd only proceed to writing if reading is stable. And even if then writing failed, well, the Prizm is bricked already, and more likely than not, the chip would be in a state where it could be rewritten again with other methods, if necessary. Am I missing some big problem with just going ahead and connecting the microcontroller to the flash pins?


IF we can read we can write. The problem with that is everything seems to share the same vcc which means I power the flash I power everything and with out control of the ram OE/CE lines it will try to talk to me as I talk to the flash garbling everything.. and same when i go to write and i wont have any clue what I am actually writing.
Double post for "new" ideas

Working with the Second Flash idea. Gbl08ma and I were discussing the idea of putting a custom boot loader with a proper boot loader payload on it. Load it to ram disconnect the Second Flash and reflash the bootloader. Then proceed to follow the normal Busted OS fix.

Issues. Telling the old flash chio to shutup. Ways todo this vary from cutting the trace and soldering in a FET to trying to get it stuck in a hiatus mode before starting the calculator. Not really easy either way.

Quote from irc
So it would be load secondary flash bootloader -> get ram execution -> restore flash while in ram (not this is a completily silent operation if done right) -> replace bootloader with new one -> Restart -> upload new upload n run to replace os
The only "problem" with such an approach I can see, is that by immediately proceeding to replace the damaged bootloader with a new one, and then installing the OS, we lose the opportunity to get a flash dump from a broken calculator.
The idea of getting such a dump would be to confirm in what state the bootloader was left, and to compare the flash section pertaining to the OS to see if it is damaged in any way too, by comparing it to a good OS dump. Perhaps in AHelper's case this is not so interesting (he was also messing with the MMU and exception handler, so there can be other strange things related to that but not directly to the bricking), but it would be more interesting in cases such as that of flyingfisch's calc, where the calculator was new and broke within some hours of usage.

However, with the second flash approach there's no good way I can see to send the data back. Developing drivers for USB or 3-pin UART is probably too much work (remember we can't use syscalls), and eventually we lack the knowledge to get a good-enough driver for either. Given that we're only interested in the bootloader and OS sectors, which amount to less than half of the sectors, on a first stage the custom "bootloader" copied to RAM could copy the relevant sectors to the second NAND (and still have space left), but this would be a painful process:
- Calculator boots from second NAND;
- Code in Second NAND copies payload to RAM;
- Payload waits for the original NAND to be connected (don't ask me how we are going to signal that we have switched NANDs; is keyboard access easy enough?);
for(int i = 0; i < num_sectors_to_copy; i++) {
- Payload copies sector i from original flash to RAM (not overwriting itself, of course);
- Payload in RAM waits for the NANDs to be switched;
- Payload copies buffered sector to the second NAND at a preset sector + i;
- Payload awaits for NANDs to be switched again;
}
In the end, you'd have the sectors you'd like to copy at a certain offset in the second NAND, which you could then read externally... but it's an extremely painful and error-prone process, you'd need to switch NANDs like 80 times to copy 10 MB.
It's probably too much work, when we can just focus on copying on sector from one flash to another (the bootloader).
Well it would not immediately replace it. It would simple load a sane bootloader let us run a preflashed payload or send a payload via the arduino. In some fashion.

Sadly you are write reading the nand off is still a pain. But once we have Code execution we can do this a few ways. Be it OCRing the screen by copying the data to it or doing some copy to ram then to the old flash mumbo. OR like you said to another sector in the old flash and then grab it once we have an os again.
Reading the screen for data... do we know enough about the screen and the way it is connected to be able to control it without any help from the OS? Not that it is a problem if we don't (there are always the other methods you described), but I'm genuinely curious.
To be honest i dont know. But it would be kinda cool to play with the prizm in an OS less state anyway. With only the settings the bootloader provides (if any)
From an EE perspective, I'm positive that you can isolate the power and/or enable lines of the flash chip so that you can do as much in-circuit communication with it as you want. In the worst case, you might need to cut a trace or two, but I think it's reasonable to assume that you can force your enable lines on RAM and Flash to be exactly where you want them. With that said, making sure you actually know where those lines are, especially for what I suspect is RAM under that smaller blob, is quite the challenge I assume you'll need to surmount.
Well that is exactly why this latter idea came about. I have no sane/cost effective way to locate the CE line on the ram chip. Nor the reset line on the cpu if there even is one that is not tied to the reset circuitry. With this latter method We only have to cut one trace. Tho it does make the software side a little tricky. It would work. Todo just a plain ICP approach I really need spec sheets on the 2 hidden chips :/
Yeah, cutting the VCC trace and powering the Flash chip directly seems like a good idea to me. Of course, if the RAM chip or the CPU have inputs that pick up some noise when they're not powered, you might run into issues, but hopefully not.
Vcc for the flash chip hides underneath it sadly Sad and with that its not a safe way to leave it in circuit. We are also trying to get a piece of hardware that we can leave inside the prizm and with a button begin an unbricking procedure.
Geekboy, have you tried testing the remaining testpoints for jtag? With data/address known as well as others, should be much easier to check.
I have no working prizm to check for them and most of the remaining test points are not for the address bus they go to random pins :/ so sadly no I have not looked into it as much as I could.
As talked about on IRC, I could try communicating with the Prizm's flash chip using CFI code running on a BBB. I'll have to get something around 36awg wire. In terms of connectivity, will there be any sort of special wiring for this, or is the flash chip happy with communicating directly to 3.3VDC digital GPIO pins? (Just putting this here, I will either get to this sometime during this quarter or over the summer)
You can connect it directly and hope that the prizms Cpu does not interfere. Once you put any power on to the VBUS it will power up teh ram as well as the flash. That being said you need to find a way to isolate the flash. That's the main issue I was having above.
I now have access to oscilloscopes and such, so hopefully I can find some wire to use and probing the flash, ram and cpu.
Yeah that might be awesome information! lol please let me know if you find anything cool Razz
To get the board to be initially powered, attaching USB to it should be ok, right? I know you can remove batteries when USB is attached and the calc can remain on so long that the OS doesn't check the ADC, but not sure if it can boot with that.

Also, if the CPU keeps running and accessing the flash and/or RAM, I'd have problems I assume. Do you think keeping the reset switch closed will be enough?

Anyways, I really need to play around with this.
From my tests that has worked. If not you can rig up some batteries its not that complicated Razz
The reset switch from my probing seems to reset all the peripherals. Including the flash and the ram. So you would have to cut the reset line trace and hold it your self But that _Should_ work if memory servers correctly.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 4
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement