Flash storage

[medelec35]

Devices like 16F15xx support flash storage (within SAF area) to work same as EEPROM component.
Is it viable to create a component that allows non-volatile storage when it has flash storage instead of EEPROM?

[Benj]

Hi Martin,

Just been having a look for you. It certainly looks possible though maybe not 100% straightforward in that you need to know the flash address of the SAF area, this could come from the FCDX.

Shame it's not on the 16F188xx devices we use on the E-blocks 2 board or I would have a nice easy platform to test out the code.

[medelec35]

I will send you a PM

Edit:
PM sent.
Hopefully it helps?

[Benj]

Hi Martin,

Yes thanks that helps quite a lot. Which specific device are you using and I'll put together an updated definition file and CAL C file you can test out to check it's going to work before we roll it out.

[medelec35]

Hi Ben,
16F15F324 & I also have 16F15375 if want it tested on two devices?
If not, 16F15F324 will be the one.

[Benj]

Hi Martin,

I've just pushed a new update including updated FCDs, EEPROM CAL C file and EEPROM CAL Component.

Fingers crossed it will work correctly for you but let us know how you get on.

[Benj]

I've just thought of a problem, the initial values won't work correctly.

Not sure if there will be a way to initialise the values in C code but there might be. Is this something you can investigate?

[medelec35]

Hi Ben,
I get the following when compiling a test flowchart:

Code: Select all

Target folder: C:\FCTEST~1
Source name:   C:\FC Testing\Flash storage1.fcfx
Title:         
Description:   
Device:        PIC.16F.16F15324
Generated by:  Flowcode v8.1.0.8
Date:          Wednesday, December 19, 2018 14:08:48
Users:         1
https://www.matrixtsl.com
Launching the compiler...
C:\Program Files (x86)\Flowcode\Compilers\pic\batch\pic_xc8_comp.bat  16F15324 "C:\FCTEST~1\" "Flash storage1"

C:\FCTEST~1>C:\PROGRA~2\Flowcode\COMPIL~1\pic\batch\..\bin\xc8.exe --chip=16F15324  "Flash storage1.c" --MSGDISABLE=359,1273,1388 --FLOAT=32 --DOUBLE=32 
Microchip MPLAB XC8 C Compiler (PRO Mode) V1.45
Build date: Nov 15 2017
Part Support Version: 1.45
Copyright (C) 2017 Microchip Technology Inc.
License type: Node Configuration

C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\PIC\PIC_CAL_EEPROM.c:
    47:		#warning "Be sure to enable the Storage Area Flash (SAF) in the device configuration settings"
	                                                                                                     ^ (162) #warning: "Be sure to enable the Storage Area Flash (SAF) in the device configuration settings" (warning)
    50:		#define MX_EE_Flash_Address	0x1F80
	                                             ^ (111) redefining preprocessor macro "MX_EE_Flash_Address" (Flash storage1.c: 168) (warning)
C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\PIC\PIC_CAL_EEPROM.c: FC_CAL_EE_Write()
    77:	FlashRowData[i]= DATAEE_ReadByte((Address & 0xE0) + i);
	                 ^ (361) function declared implicit int (warning)
using updated 32-bit floating-point libraries; improved accuracy might increase code size
.

C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\internals.c: 77: (1090) variable "_FCI_TMP_INT" is not used (warning)
C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\PIC\PIC_CAL_EEPROM.c: 49: (1090) variable "_offset" is not used (warning)
Flash storage1.c: 47: (1090) variable "_FCLV_LOOP2" is not used (warning)
Flash storage1.c: 46: (1090) variable "_FCLV_LOOP1" is not used (warning)
C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\internals.c: 76: (1090) variable "_FCI_TMP_STR" is not used (warning)
C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\PIC\PIC_CAL_EEPROM.c: 77: (1464) number of arguments passed to function "_DATAEE_ReadByte" does not match function's prototype (warning)
0: (499) undefined symbol:
	_DATAEE_ReadByte(Flash storage1.obj) 
(908) exit status = 1
(908) exit status = 1

Error returned from [xc8.exe]

C:\Program Files (x86)\Flowcode\Compilers\pic\batch\pic_xc8_comp.bat reported error code 1



FINISHED

Not sure if there will be a way to initialise the values in C code but there might be. Is this something you can investigate?

If I can, I will help
Btw, I did not write the code, it was written for me.

[Benj]

Hi Martin,

Thanks for letting me know. I believe I have solved the issue now and re-uploaded to the update system.

I wonder if something like this would do the job of the initialisation. I'm adding it using the supplementary code feature and it's compiling which is a good start.

Code: Select all

const char iniData[224] @MX_EE_Flash_Address = {0,1,2,'A','b',"Hello"}; 

[medelec35]

Hi Ben,
Thank you and Great job!
I can confirm that the 16F15324 now has EEPROM capabilities as EEPROM read and write is working!

I wonder if something like this would do the job of the initialisation. I'm adding it using the supplementary code feature and it's compiling which is a good start.

CODE: SELECT ALL

const char iniData[224] @MX_EE_Flash_Address = {0,1,2,'A','b',"Hello"};

I added it to the supplementary code (Definitions and function declarations).
Although no warnings with xc8, when loaded code into IPE it displayed:

Flash storage warning.png

(4.9 KiB) Downloaded 2435 times

[Benj]

Hi Martin,

Ok that's brilliant glad it's working well for you. It certainly was a massive help to have known working code to look at.

Can you confirm you have tested address locations of 32 and greater, I just want to be sure my maths is ok when working out the specific flash row to clear and restore etc.

I could potentially hide the initialise property for the SAF type EEPROM devices until we find a workable solution. Strange the IPE is flagging the issue? Maybe it is looking at the config values and making a judgement call?

Are you aware of any other device families with this feature by any chance? Currently I've just added it for all the 16F153xx devices.

[medelec35]

Can you confirm you have tested address locations of 32 and greater, I just want to be sure my maths is ok when working out the specific flash row to clear and restore etc.

No sorry not tried that yet.
I will try that tomorrow as will have more time then.

Strange the IPE is flagging the issue? Maybe it is looking at the config values and making a judgement call?

I can still program the chip and see what happens?

[medelec35]

Hi Ben,

Can you confirm you have tested address locations of 32 and greater, I just want to be sure my maths is ok when working out the specific flash row to clear and restore etc.

I have now tested all 128 addresses and everyone is storing correct data.

I could potentially hide the initialise property for the SAF type EEPROM devices until we find a workable solution. Strange the IPE is flagging the issue? Maybe it is looking at the config values and making a judgement call?

I have tried the read/write test with

Code: Select all

const char iniData[224] @MX_EE_Flash_Address = {0,1,2,'A','b',"Hello"};

IPE was correct to flag a warning up, as all address locations are read as 0 instead of the correct 255 when not written to.

Are you aware of any other device families with this feature by any chance?

A search brought up:
PIC16F15xx
PIC12F157x
PIC16F145x
PIC16LF1779
PIC18(L)F26/27/45/46/47/55/56/57K42
Probably more?

Was wondering why 128 bytes?

SAF1.png

(154.83 KiB) Downloaded 2409 times

[Benj]

Hi Martin,

I have now tested all 128 addresses and everyone is storing correct data.

Brilliant thanks for this.

A search brought up:
PIC16F15xx
PIC12F157x
PIC16F145x
PIC16LF1779
PIC18(L)F26/27/45/46/47/55/56/57K42
Probably more?

Thanks I'll get these added to the list.

Was wondering why 128 bytes?

there are 128 locations each with a 14-bit value which adds up to 224 bytes. Currently as per your demo code we are treating each location as a 8-bit value only and not using the higher 6 bits. In theory it should be possible to get all 224 but the CAL code would have to do things like read/write multiple locations using masking etc.

I might have a go at this at some point but for now I took the easy road to keep things simple.

[medelec35]

Hi Ben,
Your welcome.

there are 128 locations each with a 14-bit value which adds up to 224 bytes. Currently as per your demo code we are treating each location as a 8-bit value only and not using the higher 6 bits. In theory it should be possible to get all 224 but the CAL code would have to do things like read/write multiple locations using masking etc.

I might have a go at this at some point but for now I took the easy road to keep things simple.

Thanks I'll get these added to the list.

No guarantee they are all compatible as not had time to look at each datasheet to confirm.

Oh I see, Thanks for explaining.
Not an issue.
Personally happy with the current 128.
If that changes will let you know.

I will still test 16F15375.

[balles]

Hello!

If I got the SAF area right, that is, it's related to emulated EE in flash, you can use this page to mark that specific capability and find out the models that have it. And all others caracteristic too...

https://www.microchip.com/maps/microcontroller.aspx

Happy newyear!
Cheers!
Balles

[rnicos]

I tried to add the flash storage component to my project which is using a PIC16LF15375 and I am getting the compiler error shown below. I am using Flowcode 8. First, does anyone know if this flash storage component would work on a PIC16LF15375? Second, how would get rid of the error? How do you switch to 24 bit floating point?

Thanks, Reg


Microchip MPLAB XC8 C Compiler (Free Mode) V1.45
Build date: Nov 15 2017
Part Support Version: 1.45
Copyright (C) 2017 Microchip Technology Inc.
License type: Node Configuration

C:\ProgramData\MatrixTSL\FlowcodeV8\CAL\PIC\PIC_CAL_EEPROM.c:
55: #warning "Be sure to enable the Storage Area Flash (SAF) in the device configuration settings"
using updated 32-bit floating-point libraries; improved accuracy might increase code size
0: (1347) can't find 0x11 words (0x11 withtotal) for psect "text19" in class "CODE" (largest unused contiguous range 0x10)
updated 32-bit floating-point routines might trigger "can't find space" messages appearing after updating to this release; consider using the smaller 24-bit floating-point types
0: (1347) can't find 0xD words (0xd withtotal) for psect "text5" in class "CODE" (largest unused contiguous range 0x2)
0: (1347) can't find 0xC words (0xc withtotal) for psect "text17" in class "CODE" (largest unused contiguous range 0x2)
0: (1347) can't find 0xB words (0xb withtotal) for psect "text7" in class "CODE" (largest unused contiguous range 0x2)
0: (1347) can't find 0xB words (0xb withtotal) for psect "text23" in class "CODE" (largest unused contiguous range 0x2)
0: (1347) can't find 0x7 words (0x7 withtotal) for psect "text25" in class "CODE" (largest unused contiguous range 0x2)
0: (1347) can't find 0x7 words (0x7 withtotal) for psect "text26" in class "CODE" (largest unused contiguous range 0x2)
0: (1347) can't find 0x6 words (0x6 withtotal) for psect "inittext" in class "CODE" (largest unused contiguous range 0x2)
0: (1347) can't find 0x6 words (0x6 withtotal) for psect "clrtext" in class "CODE" (largest unused contiguous range 0x2)
0: (1347) can't find 0x3 words (0x3 withtotal) for psect "text4" in class "CODE" (largest unused contiguous range 0x2)
(908) exit status = 1
(908) exit status = 1

Error returned from [xc8.exe]

[medelec35]

Hello.
The errors are caused by your microcontroller running out of space.
for example

Code: Select all

0: (1347) can't find 0x11 words (0x11 withtotal) for psect "text19" in class "CODE" (largest unused contiguous range 0x10)

This means that 17 program commands or constant values are required for the microcontroller memory, but the largest unused block is 16.

Is it possible to make the code within your project more efficient?
Perhaps use fewer variables and use local instead of global variables.
Reuse the global variables for more than one function.
Use the smallest variables/arrays/strings possible.
If repeated functions, use more user call macros.

Another way is to change the current microcontroller to one which has more memory available.

How do you switch to 24 bit floating point?

That is a step backwards but it has been covered here.

Finally if still using the F153xx series, check you have changed SAF Enable from Disabled to Enabled

[rnicos]

You were correct, it was running out of memory space. The flash storage takes up about 10% of the memory.

Thanks much!

[rnicos]

Now that the flash storage is working (with SAFEN enabled), I have noticed what seems to be a memory conflict. For example, the IO pin D2 data is being over-written.

I'm using PIC16LF15375, Flowcode 8 and the compiler is:
Microchip MPLAB XC8 C Compiler (Free Mode) V1.45
Build date: Nov 15 2017
Part Support Version: 1.45
Copyright (C) 2017 Microchip Technology Inc.
License type: Node Configuration

Is there something I'm missing with the memory management? I thought the coder should do this once SAFEN is enabled?

Any idea what could be going wrong?