storing data in flash memory

[David Stephenson]

I'm using a 18F47k42 which has 128k bytes of flash so plenty to use as extra storage.
Problem is that I can't seem to get it to work. Here's the subroutine.

sub flashwrite(SPEC)
tblptru=1 'write  to highest 64k
tblptrl=fladdr 'load address 22 bit!
tblptrh=fladdr_h
tablat=SPEC
tblwt+*
tablat=SPEC_H 'load data as separate bytes
tblwt+*

set NVMCON1.REG0 OFF ' Point to flash memory
set NVMCON1.REG1 ON  
set NVMCON1.wren ON  ' Enable writes
SET NVMCON1.FREE OFF
SET INTCON0.GIE OFF
NVMcon2=0x55
NVMcon2=0xAA
SET NVMCON1.WR ON
SET INTCON0.GIE ON
set NVMcon1.wren off

end sub

[Anobium]

Search the Help. I believe we have routines for this. Someone help here with my memory loss.

[David Stephenson]

Yes there are routines, but not for all (most?) devices. It seems that microchip change the method for writing to flash memory on a regular basis.

[David Stephenson]

I've tried everything I can think of. The GCBasic routine does not work for this chip (the registers are wrong).
I've got all this in the cofiguration line (as I am of the feeling that it is some kind of acess problem)
config MCLRE=off, WDTE=Off, boren=off, zcd=off, cp=off, safen=on, wrtsaf=off, wrtd=off
And I've tried writing a whole row (as is recommended) and this also did not work.

I have attached the routine I have used on 4 other chips (which all work).
I'm going to have to resort to an external memory chip if I can't get this to work soon.
Any insights will be welcome.

[Anobium]

The K42 parts are very different from the previous parts. I2C, Serial and memory addressing all need very serious work to get operational. I have not looked in detail for this functionality.

I know that the K42 memory routines are different from the existing approach. So, if you are in a hurry - use external. I will add this to the jobs to be done.

[Anobium]

In theory this should work. It is untested. New methods match the Microchip methods so, de bugging should be easier.

This is build to be a library, so, please complete as a library. Test as a user program so I could resolve missing variablle.

Public are following methods ( we may have to prefix with K42
** FLASH_ReadByte_K42
FLASH_ReadWord_K42
FLASH_WriteByte_K42**

There will be errors - so, enjoy and get debugging. And, repost the working library.

Enjoy.

Evan

'Public are following methods v1.01
    'FLASH_ReadByte_K42
    'FLASH_ReadWord_K42
    'FLASH_WriteByte_K42


    #chip 18F47K42

    #define WRITE_FLASH_BLOCKSIZE_K42    128
    #define ERASE_FLASH_BLOCKSIZE_K42    128
    #define END_FLASH_K42                0x020000

    #option Explicit

    dim myFlashAddress as long
    myFlashAddress = 0x7D00

    dim mybyte as Byte
    mybyte = FLASH_ReadByte_K42  ( myFlashAddress )


    dim myword as Word
    myword = FLASH_ReadWord_K42 ( myFlashAddress )

    myByte = 0x55  ' the byte to write
    dim myBuffer( WRITE_FLASH_BLOCKSIZE_K42 )
    FLASH_WriteByte_K42( myFlashAddress, myBuffer, myByte )

end

[Anobium]

The master file this new functionality is here.

https://github.com/Anobium/Great-Cow-BASIC-Library-Development/tree/master/K42EEDataMethods

Please update GitHub and let me know when you have updated.

Thank you,

Evan

[David Stephenson]

Thanks. I will try it out. The #asmraw seems to be the only difference in these routines to the ones I am trying - what exactly does it do? You also mentioned that hard I2C could cause problems do you think it would be prudent to use software I2C (I am using a FT201X I2C to USB to transfer data - haven't set it up as yet)).
Sorry to keep bothing you when you are on holiday.

[Anobium]

@David your post made my smile. If there is any similarity to anything previous then it is purely by chance. I started with the Microchip methods and refactored.

Please adapt what I have posted. I want to know we started with a good resource.

The #asmram is new directive that was added this week. This will ensure the compiler produces the exact asm that you want - there, is no processing except for the spaces.

Re hardware I2C. I would use the hardware I2C routines. I worked with Microchip development to resolve the timing issues and the new methods they introduced with these new parts. All works very nicely. So, no need to be prudent, but, only time will tell if this is the case.

Cheers.

[Anobium]

@David your post made my smile. If there is any similarity to anything previous then it is purely by chance. I started with the Microchip methods and refactored.

Please adapt what I have posted. I want to know we started with a good resource.

The #asmram is new directive that was added this week. This will ensure the compiler produces the exact asm that you want - there is no processing except for the spaces.

Re hardware I2C. I would use the hardware I2C routines. I worked with Microchip development to resolve the timing issues and the new methods they introduced with these new parts. All works very nicely. So, no need to be prudent, but, only time will tell if this is the case.

Cheers.

[David Stephenson]

Have any of these routines been tested? They are essentially the same as I have been trying based on the information in the datasheet. The only difference I can see is the tabwt and tablwtpostinc which are not in the datasheet (I use tabwt+*).
Even so this is not part of block deletes and I am not getting block deletes either.

[Anobium]

In theory this should work. It is untested. New methods match the Microchip methods so, de bugging should be easier.

Tested now. These methods are 100% based on the Microchip methods as defined in MPLAB-X 4.20. Use these methods as it will make issue reporting a lot easier.

Some context. These K42 did cause us a lot of issues and the K42 implementations a number of new features/capabilities. Memory addressing, I2C, SPI were all different. And, I got a lot of support from Microchip to resolve the issues.

Even though the EEData library is based on the MPLAB-X library these still may not work.

So, try using MPASMX rather than GCASM. This will rule out issues with GCASM and any potential issues within GCASM. This will help with diags - try and let me know what happens. You need to install MPLAB-X and you will find MPASMX in the MPASMX folder.

And, I would use MPLAB-X to validate the functionality. Create a project and test. Why? I2C failed using MPLAB-X.... so, I knew Microchip had to fix. Could be the same for for EEData?

[Anobium]

An update.

I have created an MPLAB-X 4.20 project (see URL to GitHub). This fails write a byte or write a block. There are errors I have correct in the code sample generated by MPLAB-X. :-( I corrected the error. MPLAB-X project fails. Therefore, we do not have a working reference model.

I have tried MPASMX to complile Great Cow BASIC ASM. This fails with three ASM failures. No good. Therefore, you cannot use Great Cow BASIC GCASM whilst these errors exist.

My setup. 18F24K42 with PICKit2 Plus. On real silicon.

So, based on these tests. Time for me to contact Microchip Support and as them for proof. They are very use to me asking for proof that something actually works.

Your call. But, I would recommend changijng the microcontroller, or use external memory. We need Microchip to look at producing proof and we will be some time to sort our generated ASM.

Evan

---

Select here for GitHub

I have included in GitHub. The K42 Great Cow BASIC EEprom tests - these work. :-)
The MPLAB-X project.
The error log from MPASMX. This is need by Hugh to review the compile issues.

[David Stephenson]

Thanks for all your help. It is a bit puzzling (there are, I presume, only so many HEX code instructions how can it end up so complicated).
I ordered this chip because of its large RAM (I am intending to read a 1024 element diode array) and the large program memory made it attractive to use as auxillary storage rather than have an external memory chip (which will no doubt take a bit of time to get working correctly).
Does the SPI work? I have a 4Mbyte flash (A25L032) which uses SPI.

[Anobium]

Not sure I understand. Are you going validate the issues or accept them? As I need to open a ticket to get this on the road to resolution. What iis the plan?

---

PIC16F19197 is an option for you - smaller memory but still large memory.

SPI - SPI is relatively easy. Look at the demos. C:\GCB@Syn\GreatCowBasic\Demos\SPI Solutions

But, I would use FRAM. I2C fast and huge amount of RAM. And, they provide samples.

[Chris Roper]

You could also use EERAM on I2C.
It is fast and GCBasic includes drivers for it, apears as sram and is nonvolatile.
Down side is that the lagest avalable so far is 16Kb which is only 2KBytes.
Microchip will supply samples on requet.

[David Stephenson]

Yes I'm in for testing a solution, but I'm not up to using MPLAB-X.
16F19197 pity it's a 64pin TQFP. I can go back to using a 16F1789 for the moment as I'm only using a 256 pixel diode array at the moment.
I've used these SPI flash chips for other projects (as I ordered 10 I have plenty left) so I know how to read/write and erase. I use them because they are non-volatile, cheap, and big enough (4Mbytes are plenty)

[Anobium]

I will wait   until   your tests   are complete   and results   posted. No   point of me opening a ticket   when you   may have more to add on the Flash write   /   read   issue .

[Anobium]

Resolved. Without Microchip but with Hugh's good input.

See https://github.com/Anobium/Great-Cow-BASIC-Library-Development/tree/master/K42EEDataMethods/18F24K42

The issues is the Microchip reference code may be doing some 'special changes' during compilation. I know this for a fact that with respect to EEPROM they stuff NOPs into to generated HEX. So, today, after speaking with Hugh he told me that the Microchip compiler made be doing further processing for the FlashData on these parts. So, I adapted the ASM again this time using the approach I had used for the EEPROM on these parts, remember I has sorted out EEPROM as part of the initial release of test code/demos for the K42s. And, then, removing all RAWASM I revised and optimised.

Note: You have to write the whole block of FlashData according to the data sheet. 'A write to program memory or program memory erase is executed on blocks of n bytes at a time.' Where 'n' is 128 bytes. So, to optimise usage you should populate the EEDataBuffer byte by byte and then write the block - this was this will be a lot faster.

The demo write a bytes, reads a byte to one address. Then, subtracts one from the read byte and then write to a new address.

Seems to work OK.

[David Stephenson]

Thanks to Hugh and Evan.
So it is really just a matter (when writing) to check the WR bit of NMVCON1 to make sure the write is complete before proceeding. (and throw in a few nops to make sure).

[Anobium]

No. Not at all. According   to data sheet and reference   code you   need the block write with erase.

If can optimise these methods then please do. Repost so we can learn from your experience.

Do me   the courtesy of using the methods I have many hours building for you. If you   simply take the insights I have toiled to create ,  and test, into your own code then the community does not gain from your valuable validation   of the methods.

[David Stephenson]

I'm not getting this to work either with erase or write.
Should the NVMCON1.FREE bit be set for erase? I've tried this it still does not work. So either I'm doing something stupid there is something wrong with the datasheet.
Notice the flow chart (fig 13.9) in the datasheet shows a different sequence of operations - this is similar to 16F devices where the unlock sequence has to be initiated to write to the holding latches.

[Anobium]

The library I posted works. So,   you using the code I posted