Hi all: I am trying to bring up a custom designed board based on MPC8270, after spent 3 weeks on fixing hardware issues (extreme surgery !) , I finally be able to read something out of the flash and verified SDRAM is working as well. Up to this point our JTAG debugger is dead! I burned u-boot Image using a programmer and put it in. after power up and did a PORESET, I found out that every 20 seconds or so , system generated HRESET,( by measuring the HRESET pin of the JTAG port). It does read Hardware Reset Config Word when reset happens (I saw pulse on the CS0 pin). Before the JTAG die, i was able to issue "reset" command through it and found out the PC stays at 0x100, but issue "go" command , the PC became 0x000000fc and hangs. My questions are : 1. What's the best way to verify that CPU read correct HRCW ? 2. Any good JTAG debugger for this family of CPU you can recommend ? We bought Gaurdian-SE from etoolsmith (the company no longer exsit!) which really sucks!
Thanks!
lei
In message f9a7e7a80610200755h1aedf26ckbcc068fbb19b4426@mail.gmail.com you wrote:
- What's the best way to verify that CPU read correct HRCW ?
Use a debugger and/or logic analyzer.
- Any good JTAG debugger for this family of CPU you can recommend ?
BDI2000.
We bought Gaurdian-SE from etoolsmith (the company no longer exsit!) which really sucks!
The BDI2000 comes with 3 years of warranty on the hardware.
Best regards,
Wolfgang Denk
On Fri, 2006-10-20 at 10:55 -0400, Lei Sun wrote:
Hi all: I am trying to bring up a custom designed board based on MPC8270, after spent 3 weeks on fixing hardware issues (extreme surgery !) , I finally be able to read something out of the flash and verified SDRAM is working as well. Up to this point our JTAG debugger is dead! I burned u-boot Image using a programmer and put it in. after power up and did a PORESET, I found out that every 20 seconds or so , system generated HRESET,( by measuring the HRESET pin of the JTAG port). It does read Hardware Reset Config Word when reset happens (I saw pulse on the CS0 pin). Before the JTAG die, i was able to issue "reset"
Just because CS0 pulses, it doesn't mean the RCW was read successfully. Look in your CPU's manual, but I think the 20-second periodic reset means it wasn't read properly. Check that your local bus interface to the flash is identical to a known working design, for example the Freescale evaluation boards (Schematics should be available on their website). Pay close attention to the LS address bits, which, at least on the MPC8349, should use the dedicated address signals (LA27-LA31) and not the muxed ones(LAD27-LAD31). Again, check against a reference design just to be sure.
- Any good JTAG debugger for this family of CPU you can recommend ?
As others have mentioned, the Abatron BDI-2000 is excellent.
regards, Ben
Hi Ben: Thanks for the tips! We didn't use local bus interface to flash, but used 60x bus instead. I looked at the schematic and did found some difference between SDK (PQ2FADS-VR) and our board. We used JS28T256P30N95 flash, and connect all address pins to CPU's ADD pins, but the SDK use BADDR[27-29] to connect to flash's A[2] - A[0]. According to the mpc82xx manul, that should be the right way. That's so weird, because i was able to read the correct content out of the flash, after manually initialized the BR/OR register through JTAG. It shouldn't be working at all if the flash connection was wrong somehow.
Thanks
On 10/20/06, Ben Warren bwarren@qstreams.com wrote:
On Fri, 2006-10-20 at 10:55 -0400, Lei Sun wrote:
Hi all: I am trying to bring up a custom designed board based on MPC8270, after spent 3 weeks on fixing hardware issues (extreme surgery !) , I finally be able to read something out of the flash and verified SDRAM is working as well. Up to this point our JTAG debugger is dead! I burned u-boot Image using a programmer and put it in. after power up and did a PORESET, I found out that every 20 seconds or so , system generated HRESET,( by measuring the HRESET pin of the JTAG port). It does read Hardware Reset Config Word when reset happens (I saw pulse on the CS0 pin). Before the JTAG die, i was able to issue "reset"
Just because CS0 pulses, it doesn't mean the RCW was read successfully. Look in your CPU's manual, but I think the 20-second periodic reset means it wasn't read properly. Check that your local bus interface to the flash is identical to a known working design, for example the Freescale evaluation boards (Schematics should be available on their website). Pay close attention to the LS address bits, which, at least on the MPC8349, should use the dedicated address signals (LA27-LA31) and not the muxed ones(LAD27-LAD31). Again, check against a reference design just to be sure.
- Any good JTAG debugger for this family of CPU you can recommend ?
As others have mentioned, the Abatron BDI-2000 is excellent.
regards, Ben
On Fri, 2006-10-20 at 13:19 -0400, Lei Sun wrote:
Hi Ben: Thanks for the tips! We didn't use local bus interface to flash, but used 60x bus instead. I looked at the schematic and did found some difference between SDK (PQ2FADS-VR) and our board. We used JS28T256P30N95 flash, and connect all address pins to CPU's ADD pins, but the SDK use BADDR[27-29] to connect to flash's A[2] - A[0]. According to the mpc82xx manul, that should be the right way. That's so weird, because i was able to read the correct content out of the flash, after manually initialized the BR/OR register through JTAG. It shouldn't be working at all if the flash connection was wrong somehow.
We made the same mistake on our first board, which is why I'm familiar with the topic. Luckily, as you've noticed, your wiring will work for general purpose flash access, just not the reading of RCW values. From what I've read, things are done this way because at initialization the CPU doesn't know the flash chip's data bus width so it does some tricks to get the data from any width device. If you look at the first several words of your U-boot image, you'll see that each byte of your RCW is repeated 8 times.
Anyway, hopefully you can either white-wire or load your RCW from another source. In our case, we were lucky enough to have an I2C EEPROM device at the right address. Your CPU manual probably mentions several options.
regards, Ben
Hi ben: Thanks! Lession learned, Follow the SDK! clearly our hardware guy didn't. Right now our board is full of wite wire :-) . We even have to bring 32 wires out of the SDRAM to make it works!
On 10/20/06, Ben Warren bwarren@qstreams.com wrote:
On Fri, 2006-10-20 at 13:19 -0400, Lei Sun wrote:
Hi Ben: Thanks for the tips! We didn't use local bus interface to flash, but used 60x bus instead. I looked at the schematic and did found some difference between SDK (PQ2FADS-VR) and our board. We used JS28T256P30N95 flash, and connect all address pins to CPU's ADD pins, but the SDK use BADDR[27-29] to connect to flash's A[2] - A[0]. According to the mpc82xx manul, that should be the right way. That's so weird, because i was able to read the correct content out of the flash, after manually initialized the BR/OR register through JTAG. It shouldn't be working at all if the flash connection was wrong somehow.
We made the same mistake on our first board, which is why I'm familiar with the topic. Luckily, as you've noticed, your wiring will work for general purpose flash access, just not the reading of RCW values. From what I've read, things are done this way because at initialization the CPU doesn't know the flash chip's data bus width so it does some tricks to get the data from any width device. If you look at the first several words of your U-boot image, you'll see that each byte of your RCW is repeated 8 times.
Anyway, hopefully you can either white-wire or load your RCW from another source. In our case, we were lucky enough to have an I2C EEPROM device at the right address. Your CPU manual probably mentions several options.
regards, Ben
participants (3)
-
Ben Warren -
Lei Sun -
Wolfgang Denk