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?