Vybrid M4 Boot First XIP ...

[peterwoolley]

I am using a vybrid M4 boot first part.  I have loaded my application (which runs fine when built for and loaded to external RAM) into QSPI0 memory.

I can see the code there, but when I step through the start-up assembly code (I'm using MQX so it's part of the supplied bsp) the processor seems to just halt at an instruction that

is just decrementing a register.

Does anyone recognise this issue enough to see what I may have missed/done wrong?

[Wlodek_D_]

Hello,

Thank you for your post, however please consider moving it to the right community place (e.g. Vybrid Processors ) to get it visible for active members.

For details please see general advice Where to post a Discussion?

Thank you for using Freescale Community. 

[karina_valencia]

timesyssupport can you attend this case?

[timesyssupport]

Hi,

Unfortunately, we do not have this part, so I am unsure why the application would halt at a register decrement. Does the MQX team have any input on this?

Thanks,

Timesys Support

[karina_valencia]

cyborgnegotiator can you review this case and add your comments please?

[cyborgnegotiato]

Hi,

Did you try MQX example "bootloader_vybrid_qspixip"?

For inspiration read the How to test,debug vybrid qspiXIP bootloader project

Regards,

Jozef

[peterwoolley]

I have looked at this ... and it doesn't really cover the issue I have.

I have built an image to be located in qspi (0x2000000 + ).

I have loaded this image into our hw using IAR (I can see it in memory at the 0x20000000+ locations even after a power cycle).

When I try to run the code it halts at an instruction that should not cause any issue.  I have, once, had a version of this code that continued a little further, then halted.

The M4 seems to stop (general purpose registers no longer accessible).

For running XIP in M4 are there special settings needed for QSPI (as M4 is a slower processor than A5)?

I can only find examples that run A5 (on A5 boot first vybrid parts) no M4 on M4 boot vybrid parts.

[cyborgnegotiato]

Hi Peter,

Did you try MQX 4.1 example bootloader_vybrid_qspixip_twrvf65gs10_m4.ewp? (C:\Freescale\Freescale_MQX_4_1\mqx\examples\bootloader_vybrid_qspixip\build\iar\bootloader_vybrid_qspixip_twrvf65gs10_m4)

Compare your code and settings?

I really cant help you with provided information.

Regards,

Jozef

[michaeljohnson]

Hi Peter,

I've never seen a board that boots from the M4, so this may or may not be of relevance.

I've found that debugging the M4 executing out of the QSPI is problematic with CrossWorks for ARM. Our Vybrid customers raise this issue and I've put lots of hours in trying to fix it with no success. I've come to the conclusion that It can be done but only after the device has booted and is running i.e.attach based debugging works. There are still issues with the M4 executing code from 0x20000000 since the hardware code breakpoints don't work. The hardware data breakpoints have to be used resulting in a odd single stepping. Note also that the QSPI memory cannot be accessed so the debugger must disassemble from the ELF image rather than memory.

It could be that a debugging issue is hiding what is happening i.e is the application you are loading simple enough to work?

Regards

Michael

[peterwoolley]

OK ... so I just tried flashing the SAME image to an A5 boot first board ... and it seems to run (at least until it hits a common-or-garden exception due to HW differences).

Does anyone know if M4 XIP actually works on an M4 booting Vybrid?

[michaeljohnson]

My understanding/experience is that the device that is on the tower board is hardwired to boot from the CA5 with the CM4 disabled. There may be other devices that are configured differently - why did you think otherwise?

[peterwoolley]

Because we have a Vybrid part that boots M4 first ....

There are two variants of Vybrid (so I am told).  For our early revision boards we used the A5-booting variant, but our latest HW uses the M4-booting variety.

I can run out A5 application image from QSPI0 on our new boards, but that is not our current intention.  I checked that to make sure that my flashing procedure wasn't at fault.

Starting to think that M4-QSPI-XIP may not work too well on this variant.

[michaeljohnson]

I can't really help with this other than to suggest the obvious strategy of putting in endless loops at various points in the code and attaching the debugger to see how far it gets after boot up.

[karina_valencia]

cyborgnegotiator  can you continue with the follow up?

[karina_valencia]

Jozef Maslik  any update?

[karina_valencia]

Jozef Maslik  you action is required to  continue with the follow  up.

[peterwoolley]

The application is not simple, but runs fine when built for DRAM.

I've had issues using IAR Workbench when debugging QSPI0 applications on the A5 boot first part, but this problem is odd.

The code is there and I run for a few steps (at the moment getting to the point of trying to call our application entry point) then the core seems to halt ... looks like the memory is no longer mapped/visible as values change (only noticed this today).

I think I've done what I need to do to blow the boot fuses, but it won't come up without the debugger either (I have a serial terminal output in the app. so would should be able to interact if it's running).