EzPort Programming - MCF52211 - Unable to read status register

[jayteemo]

I'm having an issue with EzPort programming on the MCF52211.

The device successfully enters EzPort mode.
When I attempt to read the EzPort status register, I do not get a response.
The device does respond to the EzPort reset and erase commands, so I know it is getting the data.
The data(MCF52211 RX) and clock signals look good on the 'scope.
However, I get nothing on the data line out (MCF52211 TX).

I've tried various SPI baud rates and DLT and QSD values.
I'm not sure if there is anything else I can do, firmware related, to solve this issue.
Any suggestions would be great.
Thanks.
 


Message Edited by jayteemo on 2009-01-26 06:00 PM

[RichTestardi]

Hi,

What QSPI master are you using to talk to the 52211?

I have configured other V2 cores (52221 and 52233) to "clone" their flash out their QSPI master port into another chip's EzPort, if it might help you understand the process (and QSPI master initialization).

The attached files show the clone operation (in clone.c) running on top of the V2 qspi driver (in qspi.c).

My master-to-slave clone cable looks like:

  master     slave
  ---------  ----------------
  qspi_clk   qspi_clk (ezpck)
  qspi_din   qspi_dout (ezpq)
  qspi_dout  qspi_din (ezpd)
  qspi_cs0   rcon* (ezpcs*)
  scl        rsti*
  vss        vss
  vdd        vdd

-- Rich

[jayteemo]

The master is an MCF5234.

The slave device (MCF52211) enters EzPort mode successfully.
Once it is in EzPort mode, I do a read on the EzPort status register and it comes back 0xFF.
If the status register were to return successfully, with no errors, then the write enable command would be set and then the flash clock frequency would be set.

I'm able to send an EzPort reset command and the slave device resets...
Also, I'm able to send an EzPort erase command and the slave device erases.
I'm just not getting any response (reading status register) from the slave device.
And without being able to read the status, I can't do much.

The cable itself seems to be fine.  I've put the 'scope on the slave side of the cable and I get no data.

Thanks.

[RichTestardi]

This is a scope shot of my 52221 reading the status register thru ezport of another 52221.

Does yours look the same?

The MCU signals are (from top to bottom, ignoring the top four):

QSPI_DOUT

QSPI_DIN

QSPI_CLK

QSPI_CS0

-- Rich

[jayteemo]

Everything looks the same on my end, except for the QSPI_DIN.
I get no data on QSPI_DIN.

[RichTestardi]

Just to be sure, the CS* (RCON*) signal was the most critical there, you want it dropping low before the transaction (the documentation is unclear in at least one place on the sense of this ezport signal).  If you invert it or don't transition it, you'll read back 0's.

Are you reading back 0's or 1's?  From the scope channel 2 it looked like you might actually be reading back 0's???

The next thing I might do to try and isolate this is use a pull-up on the line and then a pull-down, and see if the data you read changes, indicating the ezport MCU is not actually driving the line at all, vs. driving it high or low -- you also can then see on the scope if the MCU is driving it only when RCON* is low, as it should be.

-- Rich

[jayteemo]

RCON seems to be doing what it should.  Image - Ch. 1: CLK, Ch. 2: MOSI, Ch. 3: RCON

I am reading back 0's on MISO... my mistake.

With a pull-up, MISO stayed high, the entire time.
With a pull-down, MISO stayed low, the entire time.

Thanks for your help so far.
Any other ideas?

[RichTestardi]

Hi,

The only thing I can conclude is that the ezport MCU is not driving MISO like it should...

It seems some possibilities are:

1. disconnected or misconnected pin

2. the ezport MCU has subsequently been reset, and is now out of ezport mode

    - either the rsti* pin was asserted when rcon* was not low, or

    - someone sent an ezport reset command (0xb9) when rcon* was not low

    - the ezport MCU executed a low voltage reset

3. you are sending the ezport command too soon after reset, and the ezport MCU is ignoring you

As for #3, I use a 1ms delay after the initial reset with rcon* low and that succeeds; however, with a 250us delay, the command fails, so some delay is definitely needed.

Also, you have to hold rcon* low until after the reset is complete...  Are you sure you're doing that?  I have attached a picture of my reset sequence (reset is the 5th signal, starting from the bottom -- all other signals are like the last time).

Now with all that said, if you don't issue the write enable command *before* the read status, then you *should* read back 0 status, right???

The (StickOS BASIC, see www.cpustick.com) test program I run is below:

  10 dim nrsti as pin scl for digital output
  20 dim cmd as byte, status as byte
  30 rem pulse rsti* low with rcon* low
  40 configure qspi for 0 csiv
  50 let nrsti = 0
  60 let nrsti = 1
  70 sleep 1 ms
  80 configure qspi for 1 csiv
  90 rem send write enable command
 100 let cmd = 0x6
 110 qspi cmd
 120 rem send read status register command
 130 let cmd = 0x5, status = 0
 140 qspi cmd, status
 150 print hex status

In that program scl on the master is tied to rsti* on the slave, and qspi_cs0 on the master is tied to rcon* on the slave.

At line 40, I set the "inactive" chip select state to 0, pulling rcon* low.  I then pulse the rsti* line low and delay 1ms.  Only *after* the 1ms delay do I bring rcon* back high at line 80 (doing so immediately will make it be not recognized by the slave).  Then, at line 110 I send the write enable command, and at line 140 I send the read status command.

The critical things I have noticed are:

1. the delay between reset and allowing rcon* to come high again (see attached timing diagram -- the pins from top to bottom are unused, unused, unused, rsti*, mosi, miso, clk, cs*) must be on the order of a millisecond.

2. if you don't issue a write enable command, you *should* read back a status register of 0.

Let me know what you find...  I think the fact that the ezport MCU is not actively driving MISO means either you are not really in ezport mode (despite it seeming a flash erase command works) or were in it and somehow left again (maybe even a low voltage reset???).

-- Rich

[jayteemo]

I'm using code warrior and I've stepped through the section of my code that initializes EzPort mode. 
I can see on the scope and in the debugger that the signals are where they need to be (I do have a few delays in there).

Code:

void EZPORTmode(){   // Drive RCON high MCF_QSPI_QWR = MCF_QSPI_QWR_CSIV; // RCON HIGH == active low KS_SleepTask (SELFTASK,(TICKS)500/CLKTICK);  // Drive RSTI high fs_etpu_gpio_output_high(GPIO3_CHANNEL); KS_SleepTask (SELFTASK,(TICKS)500/CLKTICK);  // Drive RCON high MCF_QSPI_QWR = MCF_QSPI_QWR_CSIV; // RCON HIGH == active low KS_SleepTask (SELFTASK,(TICKS)500/CLKTICK);  // Drive RSTI low fs_etpu_gpio_output_low(GPIO3_CHANNEL); KS_SleepTask (SELFTASK,(TICKS)500/CLKTICK);  // waiting until RSTOUT signal is low while ( SPIUartRead()&0x2 ) {  KS_SleepTask (SELFTASK,(TICKS)50/CLKTICK);  }  // Drive RCON low MCF_QSPI_QWR   = 0; // RCON LOW == active high  // RCON must be low before RSTI goes high... KS_SleepTask (SELFTASK,(TICKS)1000/CLKTICK);  // Drive RSTI high fs_etpu_gpio_output_high(GPIO3_CHANNEL);  // waiting until RSTOUT signal is high while ( SPIUartRead()&0x2 == 0 ) {  KS_SleepTask (SELFTASK,(TICKS)50/CLKTICK); }  KS_SleepTask (SELFTASK,(TICKS)200/CLKTICK);  // at this point, board should be in EzPort mode // Drive RCON high again MCF_QSPI_QWR   = MCF_QSPI_QWR_CSIV; // RCON HIGH == active low  return;}

Also, I'm not sending it (read status) too early, as I can break in the code and send it whenever I please.
I read the status register before sending the write enable command, just to ensure there are no errors.
If successful, I send the write enable command, followed by setting up the write config register.

There are some LEDs on the board that I can use to monitor the board's status.  It is in EzPort mode the entire time.

I read the status register before and after sending an erase command... the response is always 0.  The erase is successful though.  I know the erase is successful because I have a dummy program loaded initially, that flashes the LEDs.  The LEDs are solid when there is no program loaded (erased).

I'll double check the pin connection.
Thanks again.

[RichTestardi]

Is the precedence in this line wrong?

    // waiting until RSTOUT signal is high
    while ( SPIUartRead()&0x2 == 0 )

This turns into "while (SPIUartRead() & 0)", so it does nothing.

And you can release rcon* too soon.

Just a guess...

[jayteemo]

Oops!
Good catch, thanks.
Un/fortunately, the delay following the "while" was long enough for the transition (RSTOUT high->RCON high) to occur.

I've fixed the precedence and the result is the same.
Also, I've verified that the pin is connected as intended.

[RichTestardi]

> There are some LEDs on the board that I can use to monitor the board's status.

> It is in EzPort mode the entire time.

How can you detect you are in EzPort mode?  (I was not aware this was possible, but have wanted to do it more than once!)

I must admit, I'm a bit stumped...  It seems like you're having trouble entering EzPort mode since the MCU is not driving EZPQ during EZPCS*.

Have you verified some basics like the state of the TEST, BKPT*, etc. pins?  It seems you could not run your test program (which you erased) if these were wrong.  And I assume you see the expected clock on PSTCLK?

Here's one last thing I did...  I put a pull-up on EZPQ, and I noticed that a) the EzPort MCU does not drive it when EZPCS* is not asserted (which seems expected), but strangely, it also seems not to drive it during much of the QSPI transaction, as well...  Compare the two attached images, with pull-up and pull-down on EZPQ (third signal from the bottom).

I assume when you have a pull-up, you see none of the "blips" during the command transfer, which seem to me to be 200-250ns each.

-- Rich

[jayteemo]

The board that the MCF52211 runs as intended (flashing done via BDM).  It uses QSPI, the ADC, UART, timers, and many GPIO ports.  We are attempting to use the EzPort to provide an easy way for the customer to upgrade the firmware.

---

Rich T wrote:

I assume when you have a pull-up, you see none of the "blips" during the command transfer, which seem to me to be 200-250ns each.

---

With the pull-up, pull-down/normal, I get no activity on the EZPQ.  It stays either high or low the entire time.

[jayteemo]

---

Rich T wrote:

How can you detect you are in EzPort mode?  (I was not aware this was possible, but have wanted to do it more than once!)

---

On the board we have an LED for reset and then some LEDs for various outputs.  When reset is enabled, the all LEDs illuminate.  When reset is disabled, whatever program is on the flash begins to run (blinking the output LEDs in my case).
During EzPort init, when reset is enabled the reset and output LEDs illuminate.  Then when it is taken out of reset (and into EzPort), the reset LED extinguishes, but the output LEDs remain illuminated.  It isn't exactly a pure indication of EzPort mode, but it gives me a good idea as to what is going on.

I'll look into it some more tomorrow.
Thanks.


Message Edited by jayteemo on 2009-02-03 10:39 AM

Attached are captures of the bulk erase command and the reset command.
Both commands work as expected.


Message Edited by jayteemo on 2009-02-03 10:40 AM

[RichTestardi]

I noticed you are sending an ezport reset command (0xb9) -- I assume that either you are holding rcon* low while you do this, or you don't expect the chip to remain in ezport mode after that command?

> With the pull-up, pull-down/normal, I get no activity on the EZPQ.

> It stays either high or low the entire time.

That is baffling...

If you'd like I can mail you a small board you can use to talk to qspi directly -- you just hook it up to usb on one end and then wire the qspi pins to your target, and you can exercise it interactively...  It might help diagnose what is wrong -- I'm really not sure what it could be at this point...  Anyway, if you want to try it, just e-mail your address to rich@testardi.com (the board is an old prototype I don't need back).

-- Rich

[jayteemo]

Yes, when I send the reset command I expect the device to reset and come out of EzPort mode.

With power applied from the external power supply and regulated down to 3.3 volts for the microprocessor, the board can be placed into EZport mode but I can't read the status...

I have found that if I get it into EzPort mode then REMOVE the external power supply (J1 on schematic), I can successfully read the status. 

With the external power removed, the only connection to the board is the "EzPort header" (J27 on schematic) from the master board. 

From J27, the source of power is on the I/O pin RSTI that is fed from the master board. 
The power on the slave micro's power pin is 2.46 volts, which is bleeding to the rails from the I/O pin. 

So somehow RSTI can partially power the device and allow the EzPort status to be read successfully... I'm not sure what that means though  =\

http://www.freescale.com/files/32bit/doc/data_sheet/MCF52211.pdf

Message Edited by t.dowe on 2009-09-11 03:59 PM

[RichTestardi]

That is a great clue!!!  Does the problem not occur if you only have the 3.3V supply running?  I.e., if you just run J27 plus a 3.3V supply line?

I'm wondering if you might have a pin outside of the 0-3.3V range, and not suitable resistance to prevent the internal clamping diodes from being limited to the 25mA spec in the data sheet...

I assume VSTBY is within spec?

-- Rich

Message Edited by Rich T on 2009-02-05 03:17 PM

[RichTestardi]

I am also wondering if the 74ALVC164245 might be interfering with the EzPort Pins.

Is that RAdd populated or not?  (If not, it seems you'd be driving the EzPort pins when you had power.)

[jayteemo]

If 3.3 volts is applied to the board at J1 rather than the 5 volts, both voltages are equal to 3.3 volts since the regulators pass the 3.3 volts through. 

With 3.3. volts applied and the EzPort header connected, the status is not able to be read. 

Once power is removed from the supply pins and the part is power by the I/O pins from the EzPort heater, the status is successfully read...

I'm going to throw the 52211 eval board into the mix and try it as the master and then the slave and see where that takes me.

[RichTestardi]

> I'm going to throw the 52211 eval board into the mix and try it as the master
> and then the slave and see where that takes me.

If it is possible to build a board without all of the other ICs on it, that might be interesting, too.  I'd be curious if adding one of them -- especially the ones that touch the qspi data lines -- causes the problem to occur.

I also noticed that u1 and u2 (I assume only one is populated) have pinout changes depending on the package type selected, so I assume those are consistent.

Sorry, other than that it just seems baffling. :smileysad:

-- Rich

[jayteemo]

Problem resolved...

There seemed to be a bit of noise on the incoming clock and data (MOSI) lines.
The caps indicated on the schematic (C59:100pF and C58:100pF) were not actually on the board...
Once they were added, things were much better.

The status can be read back and the part can be flashed through the EzPort.

Thanks for your help.