Storing Variable at runtime in Flash for KL05

[Amit_Kumar1]

Hi

I Want to store a variable at runtime in Flash memory of KL05Z32VLF4, The example code given in codewarrior is not working. I am using codewarrior 10.5 I have attached the code present in the codewarrior example code which is not working . I tried copying some part of code and on debugging I found that the code hangs itself when we do erase or write operation , on erase operation  the error value returned by the Erase function is 0x89, which in PE_Error.h states invalid address. i.e #define ERR_PARAM_ADDRESS               0x89U /*!< Invalid address. */  

The above uc has 32 Kb Flash and I have selected 0x7C00 as the address location and for testing I am writing to 1byte only. The Read function is working fine for the 1st time . I am following the steps as 1. READ, 2. ERASE, 3. WRITE. and my program is getting hanged in Erase. Please look into the matter and provide some example codes regarding this. Thanks

Kind Regards

Amit Kumar

Original Attachment has been moved to: FLASH.zip

[bobpaddock]

I attached a subset of code I'm using in a larger project.  There is no makefile to link it all together as a standalone project.

However it has all of the parts needed from the custom linker script up to the example usage in main to show what is needed.

This was written for the KL25Z4.

[mjbcswitzerland]

Amit

I checked your project annd think that the Flash erase is OK at the lowest level.

However the generated code can't work without some additional user manipulation. Basically it has a number of land-mines which are waiting to go off  when user's don't tread carefully (and in fact understand the underlying code and operation).

1. Much is based on the variable uint8_t OpStatus who's pointer is passed to the flash initialisation FLASH_Init(&OpStatus);
In the process it is inserted into the internal flash management struct.

2. The Flash driver is interrupt driven which makes its operation a little tricky to follow and the code rather complicated. Depending on how you configure the project the actual flash operation will be put in a protected region (eg. the original demo has it put in EnterCritical()/ExitCritical() regions but your generated code doesn't have this - either it doesn't need it or it may fail later when it should be protected).

2.a. In addition the internal implementation is blocking, which defeats any potential benefits of interrupt driven operation (that is it spins internally on the same interrupt flag)

2.b. I do wonder whether there are different Flash drivers that can be chosen from since the one used looks more suitable for a multiple-plane flash design (at least if it wasn't blocking)

3. The user code is in fact spinning on the state of flash struct state (controlled by the Flash interrupt which has however already been processed when the code arrives), accessed by *OpStatus. It is waiting for it to become TRUE.

Unfortunately the state of the variable after successful flash programming is never TRUE but LDD_FLASH_IDLE (what value this actually is depends on some unrelated enum).

The first fix (and probably generally best) is to wait on the flash state. That is, rather than

  while(*OpStatus != TRUE); /* Wait while operation done */

do

  while(*OpStatus != LDD_FLASH_IDLE); /* Wait while operation done */

This would have to be changed in all flash routines (EraseFlash() etc.)

The reference project has a user cludge in it which makes it work.

In Events.c someone has added

void FLASH_OnOperationComplete(LDD_TUserData *UserDataPtr)

{

  uint8_t *OpStatus = (LDD_TUserData*) UserDataPtr;

  *OpStatus = TRUE;

}

This actively overwites the state with the TRUE value and so allows it to work,

but in a freshly generated project it is

void FLASH1_OnOperationComplete(LDD_TUserData *UserDataPtr)

{

  /* Write your code here ... */

}

(it maybe should be - "add code here if you need it to work" ;-)

That means that a freshly generated project probably can't work unless you are lucky that the TRUE and LDD_FLASH_IDLE defines happen to match up (they are in fact only one out so maybe some times you do get lucky).

In fact I am still not sure exactly how this status is operating (whether it is pointing to the internal state or has its own variable somewhere (tricky to see with CW's debugger)) but it is certainly weird and not very maintainable.

Regards

Mark

[bobpaddock]

I have a question about attachments here in the forum.  When I first looked at Amit's message I saw there was attachment of 975K that motivated me to zip up some of my own code, of only 36K, to do what I think Amit is asking.

Now I don't see his attachment, and I find no way to attach my own, that might help him out?

[mjbcswitzerland]

Bob

Try logging in and out again - it may be a forum glitch since I am seeing the attachement. To attach your own code you need to click on the "Use advanced editor" first (although you probably already know this).

The zip file is a complete CW project directory with elf, bins, hex etc. and I don't think the PE code has any basic problems (although its use may have some restrictions that user's code may get wrong - but there is no new user code there to check).

There is also flash interfacing code here Write / read the internal flash which is compatible with all KL and K parts.

However my experience shows that developers using PE will tend not to look at other code even if it is proven and solves the problem. In some cases I see people working for weeks on simple things that PE is getting wrong or doesn't really support - or works as simple demo but is not compatible with larger project requirements (I suppose they are hobbyists since I can't imagine who is paying their time to make such slow progress (?)).

Anyhow, I would wait until the problem code is shown since the basic generated test code (working alone) is functional.

Regards

Mark

[bobpaddock]

"Try logging in and out again - it may be a forum glitch"

Apparently.

"However my experience shows that developers using PE will tend not to look at other code even if it is proven and solves the problem. ... "

I don't know Amit so I can not speak to that directly in this case. He did send me a direct message asking to see the my code, so hopefully it helps him out.

I do agree with you.  I wrote something along the same lines in my blog a few years ago: Software Safety: I'm Scared

Only thing I've found PE good for is to see how to initialize a peripheral.  The code it produces, in my opinion, is a disaster, as it violates just about every coding guideline and MISRA rule, nor is it amicable to proper code inspections due to so many nested headers and indirections.

[mjbcswitzerland]

Bob

I just analysed Amit's project and have to admit that I was a little shocked at the generated code. It is highly (over-)complicated (maybe so that I could do much more in a complex system) but at the same time basically didn't work without application layer cludging due to coding that looks to be done by someone with little practical experience of maintaining project code.

Hopefully an unlucky exception but I can't see that it is Amit's fault in any way that he lost maybe a few hours or even a day's work. It however also shows the limitation of Silver Bullet solutions (aka CASE tools) since if they don't spit out what the user is hoping for the user tends to be rather up the creek without a paddle.

Regards

Mark

[bobpaddock]

"I was a little shocked at the generated code...Hopefully an unlucky exception..."

Sadly no.  I looked at CW produced code as far back as the 68S908 a few years ago.

It was bad then, and gotten worse since then.

"...if they don't spit out what the user is hoping for the user tends to be rather up the creek without a paddle."

Is it really to much to ask that it produces code to industry standard guidelines such as MISRA?

[mjbcswitzerland]

Amit

The code that you attached looks like reference code and not the code that you modified for your use. When this reference code is tested on a FRDM-KL05Z board it operates without errors.

********************************************************

*** DEMO project for the FLASH component - begin

*********************************************************

Project description:

Flash memory erase, write, read example.

+++ Step 0 - begin +++

Description: Erase FLASH memory sector

Erase PASSED

+++ Step 0 - end +++

+++ Step 1 - begin +++

Description: Write data to FLASH memory sector

Write PASSED

+++ Step 1 - end +++

+++ Step 2 - begin +++

Description: Read and verify the written data

Read PASSED

+++ Step 2 - end +++

*********************************************************

*** DEMO project for the Flash component - end

*********************************************************

I think you need to show your code that isn't working to be able to get help.

Regards

Mark

[Amit_Kumar1]

Hi Mark

In my codewarrior the demo code didn't worked . I am using custom KL05 board UART-Tx ---> PTB1 and UART-Rx--> PTB2,

attached is the test code which I tried. Thanks

Kind Regards

Amt Kumar