MPC8308 NAND driver - FCM appears stalled

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC8308 NAND driver - FCM appears stalled

Jump to solution
835 Views
dmarks_ls
Senior Contributor I

I'm in the process of writing a custom NAND driver for the CW flash programmer, for use on our custom MPC8308 board.  We do not have a NOR flash on the board, just the NAND (ST/Numonyx NAND512W).  I've written a custom target init file for our board that sets up CS0 for NAND flash, and also have a custom JTAG init file (since NAND currently doesn't contain the init word data, it's blank).  The NAND driver runs properly on the RDB, at least for reading out the IDENTIFY codes from the Samsung NAND chip, so I know the driver is capable of running properly.

 

So, I download our custom driver to the custom board in CW 8.8 and start debugging.  Problem is, the driver is not functioning.  The FCM doesn't budge, the OP field in FMR never resets to 0, and the driver just times out.  I can reproduce the fault on the RDB if I use a JTAG initialization file with it that specifies a NAND boot source (invalid for the RDB).

 

Am I missing something?  Why would the FCM simply not function, when the exact same code, just with a different target init file (RDB-specific), runs fine on the RDB?  The only stuff I changed in the target init file is making CS0 a NAND device, with CS1 and CS2 unconfigured.

 

Any clues would be useful, thanks.

0 Kudos
1 Solution
389 Views
dmarks_ls
Senior Contributor I

It turns out, we had the data bus flipped (or rather, not flipped) when connected to the NAND device.  (Why in the hell Motorola chose to designate the most-significant bit as 0, I will never understand.)  This appears to hang up the FCM when it tries to boot from the NAND.  Eight cuts and eight jumps later, the NAND responds, and we have U-Boot.  So, there you go.

View solution in original post

0 Kudos
2 Replies
390 Views
dmarks_ls
Senior Contributor I

It turns out, we had the data bus flipped (or rather, not flipped) when connected to the NAND device.  (Why in the hell Motorola chose to designate the most-significant bit as 0, I will never understand.)  This appears to hang up the FCM when it tries to boot from the NAND.  Eight cuts and eight jumps later, the NAND responds, and we have U-Boot.  So, there you go.

0 Kudos
389 Views
TomE
Specialist II

> (Why in the hell Motorola chose to designate the most-significant bit as 0, I will never understand.)

 

Then you haven't been reading this forum much. Understand the following (-:

 

http://upload.wikimedia.org/wikipedia/commons/6/6a/IBM360-65-1.corestore.jpg

 

That is an IBM Computer front panel from 1966 or so. The switches and lights are sensibly numbered in normal reading order - from left to right. Obviously designed by the Marketing Department and not by Engineers...

 

Motorola didn't control the bit order. Motorola, Apple and IBM got together to build the Power Macintosh and IBM provided the CPU and all of its design and documentation. More details if you care here:

 

http://forums.freescale.com/t5/Other-Microcontrollers/A-general-question-about-MPC83xx-Load-Store-Un...

 

http://forums.freescale.com/t5/Other-Microcontrollers/MPC5567-setting-PLL/m-p/74051#M4234

 

Tom

 

0 Kudos