vybrid-sc quadspi_load project: MCR register address?

[stephaniegoedec]

I have the vbyrid-sc quadspi_load project sort of working.  It says it erases and programs flash A, and the signal are active. But then I can't get the Vybrid to boot from flash A (Hello World doesn't run) and the quadspi_read function returns all zeros for the data.

I noticed the project has QuadSPI0->MCR pointing to offset 0x0 of the QuadSPI registers. This is in the file MVF50GS10MK50.h. 

But the Vybrid Reference Manual has no register at offset 0x0, and the QuadSPI_MCR at offset 0xF00.  Maybe the register definition in MVF50GS10MK50.h should be updated?  Or is this a mistake in the reference manual. Or am I reading these all wrong?

Has anyone else gotten the vybrid-sc quadspi_load project to load code which the Vybrid could then boot from?  Or could they read back the data instead of only zeros?

Please let me know. thanks

[lydia_ziegler]

Hi Stephanie,

Just to confirm what your setup is, you are using the TWR board, IAR, Segger?

Thanks,

Lydia

[stephaniegoedec]

Thanks for looking at this. I'm using a custom board based on the TWR-VF65GS10 Schematics (Rev G).  And the DS-5 tools.

[lydia_ziegler]

Hi Stephanie,

Have you seen the attached file?  The example helped me a lot to get my configuration set up.  Note that the program needs to start executing from RAM.  Let me see if I can dig up more details.

Hope this helps,

Lydia

[stephaniegoedec]

Thanks! Yes, I do have this file.  But I am very concerned that when in DS-5 I right-click the QuadSPI0->MCR and it goes to offset 0x0, instead of an offset 0xf00, that this is a real problem.  The compiler finds the Hello_world_output.c file, and the debugger reports that programming completed successfully. But the Vybrid does not boot into the Hello_world example when I try to boot it from QuadSPI, and also when I try the "quadspi_read()" function, it returns only zeros for the data.  I have added printf statements in the Tx and Rx procedures. I can see real data for Tx, but Rx data is only zeros.  Is there any chance Freescale has an updated MVF50GS10MK50.h file which matches the registers in the Vybrid Reference Manual, so the MCR register would be at offset 0xf00 and it would include the fifo Rx buffer at offset 0x7C?

If you have time to check these:

1. Can your system boot from QuadSPI into hello world after running this quadspi_load project?

2. Or if you add the quadspi_read() function to the end of your quadspi_load.c file, after the "done programming", does the data read back correctly from the QuadSPI memory? 

I added the following two lines to the end of qualdspi_load.c. Maybe there is a problem with them, and this is why I'm getting back only zeros for the read data?

  addr=0x20000000;     //FLASH_BASE_ADR

  quadspi_read(addr, PROGRAM_SOURCE_START);

thanks again for your time.

[lydia_ziegler]

Hi Stephanie,

How is your project going?  Did you get any further? 

[stephaniegoedec]

Hi Lydia,

thanks for checking. I did not. I was also having a lot of problems with the DS-5 tool paths changing, so the problems might be something else. Then my manager told me to work on something else.

So when you run this QuadSPI_load example, the Vybrid can then boot from QuadSPI into Hello_world?

[lydia_ziegler · Accepted solution]

Hi Stephanie,

Yes, I have been able to get this project working and boot from QSPI.  Let me pack up my project and attach it.

When you go to connect to DS-5, download "quadspi_load.axf" to the SRAM Debug.  You should be able to see the output on the UART (assuming yours is the same as the TWR board (SCI1)). 

Hope this helps,

Lydia

[stephaniegoedec]

Lydia, thank you very much for sending this.  It behaves the same way as the code I'd compiled here: the same messages appear on the Tera Term window, the "Erasing QuadSPI flash...(will take about 30 seconds)" message is instant, instead of taking even a few seconds, and after I run it and then set the boot configuration pins so that the Vybrid will boot from QuadSPI, it does not boot into hello world. 

So it is clear the problem is not my software setup. In looking at this with people here, the circuit on our board uses NOR QuadSPI flashes devices, which are different from the ones on the Tower design, so we can't use use the Tower software for this interface.  Thanks again for your time!

best regards,

Stephanie

[anthony_huereca]

Yes, different QuadSPI's will require different setup and code, since each manufacturer has a different method for programming, erasing, and reading their QuadSPI. What's likely happening is the erase command for the Spansion QuadSPI we have on the tower board is different than the erase command for the QuadSPI you have. That is the purpose of the Look Up Tables, is to allow for that flexibility.

You need to look at the LUT entries in the example code, and see what needs to be changed for the QuadSPI on your custom board by comparing the datasheets for each.

And just to clarify, the MCR is at offset 0x0. This will be fixed in the next revision of the RM. Thus the sample code header file is correct.