Vybrid VF6 and IAR

[mjbcswitzerland]

Hi All

I wanted to try to get the M4 (in a Vyvrid VF6) running with IAR in debug mode but there are some strange things going on. Therefore I am wondering whether anyone else has worked with IAR and has solved these issues?

1. If I take an IAR example that simple adds a main() with return 0; in it all is fine.

2. When I add my own reset vector table (replacing the one in the rt7m_tl.a library) I can load the code and see that the reset vectors are correct in RAM the debugger shows a different SP value and also the PC is set to what looks like a location in the ROM loader (about 0x5000). Therefore I can only debug when using the library vector, even if the values are the same. This means that the code can only be run/debugged by first manually correcting the SP and PC but it is not possible to command a rset - instead the code needs to be re-loaded. Strangeness 1.

3. Often when I load my own code there is a fatal error and the debugger says that it can't write to 0x3f000000. This is the first location in SYSram0 - if I connect without loading code, this location can be read and written by the debugger.
What I tend to find is that loading the original IAR demo is possible and then I can also load my own code again, until it maybe stops accepting it agan later. Strangeness 2.

4. I see that the default reset vector that the IAR library supplies contains the vectors up to and including the SysTick handler. It doesn't contain any peripheral interrupt vectors.
This means that code or variables are located from 0x3f000040 (after the basic vectors).

When peripheral interrupt are inserted they then overwrite code/variables and cause failure.

What I did to avoid the probelem (and still have all vectors located at the start of RAM) was to modify the linker script to reserve space for the peripheral interrup vectors, which is probably OK as a solution, but I am wondering why the initial situation effectively excludes any interrupts after SysTick to be able to be used?

Anyone with IAR experience who can shed some light?

Regards

Mark

[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!

[mjbcswitzerland]

Update 1:

I have a feeling that the debugger is unreliable. What I have found is that I can only load the program occasionally - if I repeat three or four times it does load (fatal error the first few times but occasionally it works).
In fact I managed to get my own program to run (although I had to manually change the SP and PC to allow it to start in each case) although this also stopped working after several loads and runs (although I hadn't changed any code I found that a memcpy (with valid pointers and size) would not return and IAR and its debugger would freeze during its execution and have to be shot down (and try again)).

Although there was a period where I could run the code after multiple loads (I think the demo always loaded since it is so small and larger code has less change) the sitation became so bad that I decided to give up with IAR (it crashed every time when it had managed to load without a fatal error but the code never completly ran successfully any more).

Now I have moved to DS-5 to see whether the simuation is any better. It also has a demo program "Freescale-Vybrid-VF6xx-M4_RAM" and this looked to run. It loaded and there was "Hello world from Cortex-M4" on the App Console.

Then I repeated a few times and found that it too looks to be unreliable. Sometimes I get

ERROR(CMD16-TAD11-NAL22):

! Failed to load "Freescale-Vybrid-VF6xx-M4_RAM.axf"

! Failed to write 3'136 bytes to address 0x3F040000

! General error on memory or register access.

But sometimes it does load and run, although I am not yet sure of how reliably/unreliably because it may run once but fail after a reset (which would normally re-load).

However, the fact that loading to internal RAM is failing sometimes also using DS-5 does points to a problem with the HW or the debugger.

Therefore there are new questions that are thrown up:

1. Are there known problems with the debugger on the TWR-VF65GS10 and are there updates somewhere? (I see that DS-5 calls it a "Keil Software OpenSDA CMSIS-DAP") Edit: I reloaded CMSIS-DAP.S19 from the TWR-VF65GS10-QSP but it didn't help. The board links to the P&E web site so I downloaded the latest set of SDAs but nothing for the Vybrid in it. Other threads from 2013 talk about improved features (with USB-MSD loading but it seems these didn't get done)

2. I have tried allowing a reference SW to be loaded by the Vybrid's boot loader (from SD card) as well as having no SW to load plus trying to connect during the loading process and with IAR I has best results (highest chance of it loading without fatal error) when I do it just as the loaded program is starting.  Are there rules as to the state of the processor when connecting?
In the documentation to the DS-5 reference there is this:
"Power-up the Freescale Vybrid VF6xx, let its loader initialize and prevent the OS boot."

It talks about "preventing the OS boot". But what does this mean and how is it done? Could it be relevant to the problems?

Regards

Mark

P.S. My TWR-VF65 is Rev. H.

[mjbcswitzerland]

Update 2:

Below is the DS-5 demo code that sends "Hello world from Cortex-M4" to the semihosting communication link:

int main(int argc, char** argv)

{

    printf("Hello world from Cortex-M4\n");

    return 0;

}

I have found that I can load and execute it about 40% of the time  [60% of the time there is a loading error] - I have the SD card removed, so the boot loader is not loading an application - but, although the printf() works and sends the string the code never returns from printf(). If I pause the debugger the PC is at 0xf4b6, which looks to be a forever loop in the boot loader.

Possibly there is a further problem that the code is crashing in the printf(), which could again be some form of unreliability or maybe the demo code does crash due to it not really being tested to see whether it successfully returns (?)

Can anyone confirm the behavior?

Edit: I did a number fo tests and found that it is again random - sometimes the funtion returns and sometimes it doesn't. Presently there is a lot of randomness in behavior.

Regards

Mark

[rendy]

Hello,

this looks like a debugger script issue, we cannot support examples provided by IAR.

Would it be possible for you to try to evaluate IAR or DS-5 with MQX examples? We can support this in case you will be experiencing similar issues.

Ragards

Rene

[rendy]

Hello,

give me some time to try to reproduce this. I'll let you know tommorow.

Regards

Rene