Vybrid Core Identification & Boot Issues

[brucehansen]

I have a custom board and firmware written and targeted for a MVF50NS151CMK50 Vybrid processor.

Although I am using a rudimentary RTOS, I am not using Linux or MQX (although I have ported some low-level driver code from MQX).

My code storage is a 4MB QuadSPI flash device, and I have 256MB or DDR3 SDRAM connected.

The Vybrid is configured to boot in mode 0b10 (RCON mode) and the relevant RCON pins are all pulled low to select QuadSPI0 as the boot device.

My initial set of test boards were fitted with the MVF50xx and, as long as I respected the power supply / bootup issue addressed by PCN17176, my boards booted up and executed my firmware as expected.

Recently I received a new batch of boards - these ones were fitted with new Vybrid samples with mask revision 3N02G, intended to fix the PCN17176 issue.

We were notified in advance that the Vybrid samples we received would be a 'superset' of the version we intended to use - so instead of the MVF50NS152CMK50 (single A5 core, no L2 cache), we would get KVF61NS152CMK5 (dual A5/M4 cores, with L2 cache, A5 primary boot).

Since I never enable the M4 core or the L2 cache in my code, I didn't expect this to be any issue as the 'superset' devices should behave exactly like the ones we'd planned to use.

However, after receiving the assembled boards I am now running into some issues & inconsistencies...

Immediately after assembly, the QuadSPI flash on all of the boards was programmed over JTAG (Segger J-Link connected to the Vybrid) and there were no issues - the programming succeeded and I can verify it.

But of the 8 boards I have on hand to test, only one initially booted up - and this is where the strangeness begins.

I noticed that the marking on the Vybrid IC packages wasn't what I expected. Instead of being KVF61NS152CMK5, what I have is MVF62NN152CMK40 on all 8 boards

When refer to the Vybrid datasheet to decode this part number, I find that this part 'should' be a dual-core, but with the M4 as the primary boot core, and no L2 cache.

So why did one of my boards boot when I've never written any M4 code for it?

And the strangeness continues. While JTAG'ed to the board, I can access registers in the modules - and the MSCM in particular. These registers should tell me what type of cores I have in my device as well as what cache is present.

For all 8 devices, it reports to me that I have an A5 with L2 cache as CP0 and an M4 as CP1.

But according to the datasheet & reference manual, for a MVF62xx device I should see the M4 as CP0 and the A5 with no L2 cache as CP1...

While experimenting with one of the boards - trying to get more useful information out of it, it also started to boot - and continues to do so. I don't know what I did to change it, but the firmware image is the same and I haven't blown any eFuses yet either.

If I take one of my 'non-booting' boards, and attach to it over JTAG to try to debug running code (with my debug environment expecting to interact with the A5 core), I am able to pause the device and I see the PC register in the address range of the device's internal bootloader ROM. I can single-step through this code, but since I don't know what it's trying to do this doesn't tell me much.

I also have access to the Vybrid's USB0 port, and if I take a 'non-booting' board and plug it into my PC, it enumerates as a 'HID-compliant vendor-defined device' and is recognized by the Vybrid MfgTool - which indicates to me that the ROM bootloader is in Serial Bootloader mode (mode 0b01) and not RCON boot mode (0b10) as it should be.

But, when I check the SMBR1 & SMBR2 registers in the SRC module I see the values I expect to see for RCON-QuadSPI0 boot mode (SMBR1 0x00000000 & SMBR2 0x02000001).

How do I figure out what I actually have?

Are these MVF62xx devices as marked - in which case why do any of them boot at all?

Or are these mismarked MVF61xxx devices - in which case why does a working firmware image (tested on a MVF50xx) which is programmed the the QuadSPI flash & successfully verified not work?

Why do some of these boards seem to boot to their internal ROM Serial bootloader (boot mode 0b01) instead of their configured RCON-QuadSPI0 mode?

[CommunityBot · Accepted solution]

This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

[brucehansen]

Hi Richard,

It's been confirmed that the parts I have are MVF61NS152CMK50 (A5-500, M4, L2 Cache, Security), but the factory "tested and fused these parts to the part number marked on the device, MVF62NN152CMK40". I'm not exactly sure what this means with regard to what functionality I should expect though ... 

Nevertheless, to follow up on your RCON & booting suggestions - my RCON pins 1, 4-7, 16, 31 are all pulled low with 10k resistors.
The BOOT_CFG values I am able to read from SRC_SBMR1 confirm that these pins are read as low at system reset, so I can't see any reason why my boot configuration could be anything other than QuadSPI0.
Also the fact that I can attach via USB seems to indicate that it's not in the RCON31 endless loop state, but is in boot mode 0b01 - Serial Bootloader.

It seems to me that the Vybrid is able to access the external QuadSPI flash, since the erase/program/verify operations all depend on the Vybrid being able to do so, and I have no trouble with this.

So I'm still stumped as far as figuring out why some of these MVF61xx Vybrids boot and others don't while the older MVF50xx Vybrids all boot fine with the same QuadSPI image.

Interesting to note that even though one of the old MVF50xx boards doesn't have the 10k RCON pulldown resistors populated on 1 & 4-7, it still reads these pins as being low and boots fine (the 10k's on 16 & 31 are populated). This isn't a 'feature' I'm relying on though.

I'm hoping to receive new samples soon of correctly marked & fused devices - not sure if they'll be MVF50xx or MVF61xx - but I'm still a little concerned that these new ones may not boot up for some as-yet unidentified reason...

 - Bruce

[richard_stulens]

Hi Bruce,

Let me start with the discrepancy between marking and fuses to clarify the situation for everyone else reading this thread.

These samples that your received were not from a normal production run. They were tested an labeled outside the normal production flow for the purpose of general purpose samples. In this process, these parts were incorrectly marked.

Going by the fuse and SMBR info you sent per e-mail, the parts you received are Dual core A5 primary with Speed grade 500 MHz and thus will be able to execute your A5 code. This explains why 2 boards did boot.

The reason for the non-booting parts to be in serial boot mode is quite likely because Serial Boot mode is the fall-back boot mode when the boot from the specified device (QSPI in your case) fails.

You mentioned that the 2 booting boards were initially not booting and started to boot later for no apparent reason. This triggers a thought that some of the RCON pins may be floating. Floating pins may alter the boot configuration causing the boot to fail, even though RCON[7:0] selects QSPI. Ex.  if RCON[31] is set it will send the boot in an endless loop.

I hope this covers all your questions and allows for getting the other boards to boot as well.

Best regards,

Richard

[karina_valencia]

richard_stulens‌ will take this case.