Flash frustrations

[lpcware]

Content originally posted in LPCWare by JohnR on Tue Apr 24 06:05:44 MST 2012
Hi,

I am getting thoroughly fed up with trying to flash the memory on my Diolan board using LPC-Link.

I seem to be able to flash reliably if the start address is the start of flash memory. But I want to be able to store the M3 axf file as well as the M0 file to flash. So if put the M3 at the start having partitioned the memory to be split in two, the M3 code works fine.

But then if I want to use a different start address for M0 at 0x1c100000, LENGTH = 0x100000, I almost always get the error message

Ec: Flash driver command failure 100003F0, 2

Occasionally it has seemed to work.

I have searched for a list of definitions of the flash driver error codes - is such a list available?

Thanks in advance for any help.

JohnR

[lpcware]

Content originally posted in LPCWare by sjalloq on Fri Jun 08 07:07:38 MST 2012
Thanks.  I'll take a look this weekend.  However, I only managed one successful download last night with about 10 failures.  I'm going to have to get the scope on it this weekend and see what's going on.

If the flash drivers really do use the code that is bundled in the zip files, then I wouldn't be surprised if it failed or was at least flaky and board/weather dependent.

[lpcware]

Content originally posted in LPCWare by JohnR on Fri Jun 08 05:31:02 MST 2012
Hi Shareef,

I'm glad it worked for you. In your own program, in the memory details box, is the flash memory definition the first item in the drop-down list?

Here is the file for the M4/M0 project. This is again a slight modification from the very useful project supplied by Code Red, together with a lot of help from them. The modifications were mainly adding the Diolan code for the switches and LEDs as well as the message passing between M4 and M0.

You should only need to compile the M4 side - the project was set up by Code Red to automatically compile the M0 code and include the .s file in the M4 executable.

Once the code has been flashed, the program should start by turning (M4) on the red LED, D1, for a short while. Then after a second or so, the LED D6 should light (M0). Then pressing S4 should toggle D6 on and off.

John.

[lpcware]

Content originally posted in LPCWare by sjalloq on Thu Jun 07 15:49:21 MST 2012
[Edit - just removed a post about it not working]

I just checked the project settings and noticed that the flash driver was set to the not 'B' version.  Changing that allowed me to program the flash and I have some blinking LEDs.  So thanks for that - at least I know my board isn't toast.

What I don't understand is why I can't program one of my own projects using the same flash driver.  Any suggestions on where to look? Any other default settings in my projects that would need to be changed?

John, if you could post the full multicore example I'll try that over the weekend.

Thanks again, Shareef.

[lpcware]

Content originally posted in LPCWare by sjalloq on Wed Jun 06 23:40:06 MST 2012
Thanks a lot. I'll give it a go this weekend and report back.

[lpcware]

Content originally posted in LPCWare by JohnR on Wed Jun 06 06:10:07 MST 2012
Hi,

I realised after posting the last message that one could add a zip file to a post.

So here is my version of the Hitex Blinky code using the flash memory on the Diolan board.

I now have permission from CodeRed to publish the dual M4/M0 code so if you can get Blinky working and still want the dual code, I will post it as well.

Hope this helps.

John

[lpcware]

Content originally posted in LPCWare by JohnR on Wed Jun 06 05:37:04 MST 2012
Hi,

I have a very simple NXP version of the Hitex LPC4350A_HitexA4_LedBlinky_SST project, that just flashes a pair of LEDs on the Diolan board.

I will post this later today, once I find out how to post to this forum.

John

[lpcware]

Content originally posted in LPCWare by sjalloq on Tue Jun 05 14:37:08 MST 2012
Have you got any simple projects that write to flash that you can export?  I'm having real issues getting anything useful out of the flash and I'd like to be able to say that my problems are me and not my board.

If you have a blinky LED example that writes correctly into flash  then that would be great.

[lpcware]

Content originally posted in LPCWare by JohnR on Mon Jun 04 07:43:56 MST 2012
Hi,

I am not exactly sure which example you want to get working?

In my case, I started with the Hitex LPC4350A_HitexA4_LedBlinky_RAM and simply changed the addresses for the LEDs, using the Diolan equivalents, then I did the same with the LPC4350A_HitexA4_LedBlinky_SST sample to see the SDRAM working.

In the case of the dual M4/M0 sample, again I modified the sample that CodeRed supplied using a bit of the Diolan code to react to the pushbuttons and turn on/off a LED.

John.

[lpcware]

Content originally posted in LPCWare by sjalloq on Mon Jun 04 05:44:13 MST 2012
Any steps you had to go through to get it working? Does it work with any of your projects?

[lpcware]

Content originally posted in LPCWare by JohnR on Sun Jun 03 15:48:20 MST 2012
Hi,

The support page is correct - the SST39VF3201b_Hitex_LPC1850A_4350A.cfx driver worked fine for me, at least.

John.

[lpcware]

Content originally posted in LPCWare by sjalloq on Sun Jun 03 13:07:51 MST 2012
Hi again,

no, I mean Microchip.  They manufacture the SST39VF3201B flash part that is used on the Hitex Eval board (at least that is the only manufacturer of that part number I can find).  The following page (http://support.code-red-tech.com/CodeRedWiki/LPC1850_4350_Support) suggests that the same flash driver used on the Hitex board can be used with the Spansion part on the Diolan board, but I think that is impossible due to the fact that the last cycle of the sector erase instructions are different. 

Secondly, I've been seeing some strange debug behaviour which led me to this forum post: http://www.lpcware.com/showthread.php?t=2836&langid=2.  In my case I'm getting it fall over at address 0x1c002fc4 and I have to hit reset before it jumps to main().

The problem may well be that Diolan haven't used a pullup on pin P2_7 which is used for address bit A[9].  This pin is the hardware request for ISP!!

In the meantime I've been trying to work around these issues but still haven't been able to erase the flash and read a correct data word.  :-(  Not a good days progress.

Laters.

[lpcware]

Content originally posted in LPCWare by JohnR on Sun Jun 03 10:45:17 MST 2012
Hi Shareef,

I will write today to CodeRed about posting the M4/M0 project.

At the moment I use the RedSuite compiler and Red Probe for downloading. Earlier I used LPCXpresso and the LPC_Link module for downloading code. I had a lot of problems at that time trying to get the Diolan dual M4/M0 examples working on LPCXpresso but with CodeRed's help all is well mow.

I assume you mean Micron not Microchip. I haven't checked the Spansion datasheet but the Micron device seems to behave properly on the Diolan board.

JOhn.

[lpcware]

Content originally posted in LPCWare by sjalloq on Sun Jun 03 06:22:35 MST 2012
Hi John,

thanks, that would be really useful if you could either post the code or detail the modifications needed.  I have already seen their example but it doesn't work out of the box on the Diolan board so I started looking at the flash code...

...which has opened another can of worms.  Code Red state on their website that they have customers using the SST39VF3201B flash driver bundled with the IDE but this can't be correct as the Spansion and Microchip parts have different commands.  Did you find that you had to modify the flash driver?  I'm just going through that now.

Thanks, Shareef.

[lpcware]

Content originally posted in LPCWare by JohnR on Sun Jun 03 05:16:57 MST 2012
Hi,

CodeRed have just released an example of using both M4 and M0.

http://support.code-red-tech.com/CodeRedWiki/LPC43DualCoreProjects.

They were exceptionally patient in helping me get going.

The example they sent me was for the Hitex board so I modified it to work with the Diolan board, mixing in some of the Diolan example code, using their message passing scheme to turn on/off one of the LEDs using one of the buttons.

If you would still like the code, I will check with CodeRed to see if they mind, though I don't see why they would.

John.

[lpcware]

Content originally posted in LPCWare by sjalloq on Sat Jun 02 12:31:05 MST 2012
A loaded question for you - when and where are you going to put up the details of this example so others can follow?

Hopefully I haven't just missed it on the forum.  :-)

[lpcware]

Content originally posted in LPCWare by JohnR on Sat May 05 15:34:19 MST 2012
Hi Phil and others,

With a lot of support and code from CodeRed I now have succeeded in running a simple project on my Diolan board that uses both M4 and M0. At the present M4 simply toggles a port that feeds a logic analyser and sends a message to M0 to toggle another port. Simple but it took a while to get there.

Getting Code Red's Red Suite 4 compiler and their Red Probe+ also helped a lot. LPC_Link and LPCXpresso worked but downloading was slow as the system looks first for Red Probe and only after a while accepts LPC_Link.

JohnR.

[lpcware]

Content originally posted in LPCWare by PhilYoung on Wed May 02 04:08:36 MST 2012
Since I just got a new board and experienced a similar problem this might also apply to you.
The flash programmer was not setting up ALL of the address pins on the EMC, which was not a problem initially, but on the new board there are additional address pins which if not configured by default are pulled high.

Flash programming succeeds, but the actual data is written to the wrong flash location, however it's also read back from that location and flash verfies ok.

When the program starts it configures ALL address lines, but as soon as it configures an address line that was not configured in the programmer that line goes low and the program crashes, of course in by case the image I assumed was at 0x1c000000 was really at 0x1c400000.

so check the programmer to ensure that ALL address bits are configured.

The boot loader will set these low when booting from flash, but if you use the debugger to start the code then you MUST set them to the correct mode with a script.

[lpcware]

Content originally posted in LPCWare by nxp21346 on Mon Apr 30 08:40:12 MST 2012
This definitely sounds like the best idea to me. There are two cores, but it usually makes more sense to merge the images together and download or program them at the same time. We often do this by converting the M0 image into a .c file (binary array) and compiling it into the M4 project.

-NXP

[lpcware]

Content originally posted in LPCWare by PhilYoung on Mon Apr 30 00:02:45 MST 2012
Hi John,
Perhaps the easiest solution is to make a single image containing both M4 and M0 code and flash it all together.
I wrote my own programmer as the flash on my board is different so I can't guarantee that the programmer supplied is OK.

for this mode first I create the M0 program, then run the following user command.
fromelf --cadcombined --output="..\M4\M0_image\LR0.h" ".\AGR2_M0.axf"
This creates a hex file containing the M0 image.

next I build the M4 code including a source file with the following code, this just changes the type of the hex file so it doesn't get relocated at startup.

extern const
#include "LR0.h"

then I put the followingg in the M4 linker script

LR_M0_IMAGE 0x1C040000 0x00020000  {    ; load region size_region
   ER_M0 0x1c040000  { ; root section for startup code and vector table
      cm0_image.o(+RO +RW +ZI)
  .ANY(LR0)
   }
}


Then in the M4 code I conlude the following code to start the M0
/* take SLAVE processor out of reset */
void StartM0(void)
{
volatile uint32_t u32REG, u32Val;

// Release Slave from reset, first read status
u32REG = LPC_RGU->RESET_ACTIVE_STATUS1;

// If the M0 is being held in reset, release it...
// 1 = no reset, 0 = reset
while(!(u32REG & (1u << 24)))
{
u32Val = (~(u32REG) & (~(1 << 24)));
LPC_RGU->RESET_CTRL1 = u32Val;
u32REG = LPC_RGU->RESET_ACTIVE_STATUS1;
};
}

/* put the SLAVE processor back in reset */
void HaltM0(void) {

volatile uint32_t u32REG, u32Val;

// Check if M0 is reset by reading status
u32REG = LPC_RGU->RESET_ACTIVE_STATUS1;

// If the M0 has reset not asserted, halt it...
// in u32REG, status register, 1 = no reset
while ((u32REG & (1u << 24)))
{
u32Val = ( (~u32REG) | (1 << 24));
LPC_RGU->RESET_CTRL1 = u32Val;
u32REG = LPC_RGU->RESET_ACTIVE_STATUS1;
}
}

first do    LPC_CREG->M0APPMEMMAP = (uint32_t)&LR0;
this sets the shadow address for the M0

then just call StartM0() to get the M0 running.
Both the M0 and M4 start executing code from flash, but both images perform the required relocation of their executable code to RAM independently of each other.

regards

Phil.

[lpcware]

Content originally posted in LPCWare by JohnR on Sat Apr 28 05:21:35 MST 2012
Hi Phil,

"I'm getting slightly confused now what you are trying to do." - not nearly as much as I am, although what you have sent me so far has been immensely useful.

Right now my target is to get both M0 and M4 working simultaneously on stored programs , initially without communications between them, just flashing LEDS or driving the logic analyser, using Red Suite or LPCXpresso. So far, I have had working M4 in flash, M0 in RAM, but not simultaneously. Then tackle inter-processor communications.

It would be great if NXP, Code Red or one of the LPC4300 board manufacturers could put together a seminar series on designing with these dual-core devices.

Thanks yet again,

John.