EzPort Programming - MCF52211 - Unable to read status register

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.

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).

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.

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.

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???

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???).

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).

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).

> 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.

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-0310:39 AM

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

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).

> 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.

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.

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.