Boot from Dataflash

[torbenlüdeking]

Hello Everyone

I'm trying to start an Application from the Dataflash we attached to the QuadSPI.

At first i download all necessary Files via Serial Downloader to the OCRAM.

Followed by an Application which contains it's own IVT. The task of this App is to init QSPI and write the other

Files to the Dataflash. This works perfectly fine.

The files are written to the following locations:

0x20000000(Page 0 offset 0) QuadSPI Conf. param including LUT

0x20000400(Page 1 offset 0) IVT and DCD (points to the ADDR of the IMAGE)

0x20000800(Page 2 offset 0) Image

Note: Size of a Page is 528 byte by default or can be set to 512 byte. So the offset of the image is 528 bytes and not as expected 1kb.

I'm pretty sure that my IVT and DCD are correct, it's created in the same way like the IVT for the App which writes the files to the Dataflash.

Of course with changed ADDRs. If it is correct that the QuadSPI conf. parameters +LUT are req. in Little Endian this should be also correct.

I guess there could be a Problem with the CPU to read from the Dataflash. Our Dataflash requires ADDRs in the following Format 2 Dummy Bits 12 Page Bits(which Page on the Flash to read) 10 Bits offset (start ADDR inside the Page). If the CPU expects the ADDRs to be continously this could cause Problems while reading. The Read-CMD in the LUT should still work fine if the Boot ROM doesn't calculate ADDRs by itself and just reads the whole Image at once from 0x20000400 into the OCRAM. But if it reads just pieces and calculates then a new ADDR this could be the problem (possible to generate invalid ADDRs).

So what i need to know is what does exactly happen when the Boot ROM reads Data from QSPI, does it read all at once or piece by piece ?

Best regards,

Torben

[karina_valencia]

timesyssupport can you attend this case?

[torbenlüdeking]

To make sure that there is no other source of failure i attach in this message the used IVT and qspi config parameters.

The binary i'm trying to execute on boot is really basic. It just turns two LEDs on. This behaviour works perfectly fine in if i execute my binary in OCRAM.

The QSPI Configuration Parameters (0x20000000)

00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 03 00 00 00
03 00 00 00 00 00 20 00
00 00 00 00 00 00 20 00
00 00 00 00 00 00 00 00
00 00 00 00 04 00 00 00
00 01 00 00 00 00 6B 04
18 08 08 0C 80 1E 00 24
00 00 00 00 00 00 00 00

The IVT (0x20000400)

D1 00 20 41 00 08 00 20

00 00 00 00 00 00 00 00

20 04 00 20 00 04 00 20

00 00 00 00 00 00 00 00

2C 00 00 3F F4 0F 00 00

00 00 00 00 00 00 00 00

Additionaly i observed following behaviour with the oscilloscope. I see 5 read attempts each the same width. The fact that i cant observe any activity on Data 3 or 4 leads me to believe that even reading the first Table( QSPI configuration parameters) can't be read correctly. If it would i should be able to see it using the Quad command that has been provided in the Configuration Parameters

Thanks for your help.

[alejandrolozan1]

Hi Torben,

Can you verify the commands sent by the MPU?

As far as I see these command should be default read commands to get the QSPI configuration.

I wonder if you can share the scope picture.

Best Regards,

Alejandro

[torbenlüdeking · Accepted solution]

Hey everyone,

I got the first question solved, the Vybrid CPU does read piece by piece in 256byte steps this results in invalid ADDRs for our

Dataflash. Here is one example:

This picture shows the opcode of 0x6B clocked into QSPI

by scrolling to the right we get the following ADDR:

If we count the 0's and 1's we can see that this ADDR translates to: 0x000B00

This again translates to Page 2 offset 0x300 which is invalid at a pagesize of 0x210

Judging by this i'm pretty sure Dataflash is not compatible.

[torbenlüdeking]

Hello everyone,

Yes i'm pretty sure the command send should be the discribed read command from the Ref.Man.

It can be seen on the following piucture:

TOP(Data0) Bottom(Clock). There is some noise on Data0 you can ignore this.

This should read: 00000011 (Opcode 0x03)--> Dataflash continous array read low frequency

Here is a view of the seperated read attempts. Like before only the high peaks on Data0 should be real activity.

Each read attempt works at ~18Mhz(verified).

The noise on Data0 is caused by the cables (very close) i attached to spi so i can read with Oscilloscope.

As you can see the CLK cable is the reason for this noise.

Now i attached my TOP sensor at Data1 to read the answer activity:

As you can see there is some returning data on first and second attempt. The pattern seems to be correct judged by the amount of 1's and 0's.

Interestingly there is no more response on >=third read attempt.(As before noise on Data please ignore).

Edit: I tried to read the ADR's send on each read cmd. It seems that every read is 0x40(16*4Byte) in size. This explains why there are no more Data on the end.

It's just because in this ADR range are only 0's. The calculated ADRs should be in correct range (not exceeding 0x210 offset).

And maybe it's usefull, the Dataflash we are using: AT45DQ161 | Adesto Technologies

Best regards

Torben

Ps.: I'm still a student. This is my first "big" project so i really aprecciate your help :-). I hope you can get all information from the Images you are looking for.

[karina_valencia]

timesyssupport do you  have any update?

[timesyssupport]

Hello Karina,

The Freescale Vybrid team should assist with this, as we do not have any boot from QSPI sources for Vybrid.

Thanks,

Timesys Support

[karina_valencia]

Thank timesyssupport.

alejandrolozano can you  help  here?

[alejandrolozan1]

Hi Karina,

Sure, I can afford some time.

Torben, can you provide some scope captures of the signals?

Best Regards,

Alejandro