• AVR Freaks

AnsweredHot!Anyone using the PIC16F18456? Does not seem to work correctly?

Page: 12 > Showing page 1 of 2
Author
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
2019/07/09 20:16:11 (permalink)
0

Anyone using the PIC16F18456? Does not seem to work correctly?

Hello All,
To start things off, I am 100% self taught in the fields of electronics, programming, and PIC MicroControllers, so, sorry if I do not get all of the terminology correct, or if I seem to not know something that seems as though it should be obvious.
 
Looking for someone with experience with the 16F18456. It seems that unless I declare every variable as static, they lose their value between program cycles. I understand that this is common behavior for an automatic variable to not retain it's value between function calls, but, I am referring to local variables in the main function.
 
For example, I declare (inside the main function) "uint16_t backLight = 1023;" Then I call my PWM function once a second, loaded with the value "backLight", and even tho I do not change the value of "backLight", the back light of my LCD changes to random brightness levels every second as the PWM gets loaded with a new random (or not random, I do not know where the value is coming from). I can alleviate the problem, by declaring the backLight var as "uint16_t static backLight = 1023;" , however, I do not believe I should have to define a local var as static, for it to retain it's value? (I am starting to run into problems with passing static variables between modules. With the version 2.05 compiler, I ran into an issue where if I assigned a static variable the value of another static variable, then assigned a third static variable that value, the program would seem to bog down, and run very slowly. 1.45 does not have that particular issue)
 
I have worked with several other both 8 bit and 16 bit microcontrollers from Microchip, and have never come across this problem before. This is a fairly new micro, and I had to get the latest (2.05) XC8 compiler, as the 1.45 I was using did not support the chip. After having a lot of issues with the Version 2.05, I went back to 1.45, and downloaded the part-support update, so I could try 1.45 with this chip. The 1.45 version seems to mostly work, except for the requirement to declare nearly every variable as static. (Also had to write my own EEPROM routines, as 1.45 does not seen to have built-in support for EEPROM reads & writes). I should also mention I am using MPLABX 5.15.
 
Sorry for the long windedness, but am trying to describe as best as I can the issue. This thing has been beating me for days, and there seems to not be much info available via a google search, and even this forum produces zero results for 16F18456.
#1
ric
Super Member
  • Total Posts : 23185
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/09 20:26:09 (permalink)
+1 (1)
Please post a small, complete program that demonstrates the issue.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#2
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/09 23:03:46 (permalink)
0
I tried tonight to create a small program to replicate the problem, I could not. The project I am working on is quite large, using SPI, EEPROM, PWM, several Timers, and I am as yet unsure what seems to be causing the issue. I will try to build the smallest program that still creates the issue, and will upload then. Bedtime now, thanks for the quick response.
#3
ric
Super Member
  • Total Posts : 23185
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/09 23:11:39 (permalink)
+2 (2)
davez...
(Also had to write my own EEPROM routines, as 1.45 does not seen to have built-in support for EEPROM reads & writes).

On PIC16F chips, XC8 lets you directly place any sort of variable directly in EEPROM, and manages all the low level reading and writing for you. Look up the "eeprom" qualifier in the user guide.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#4
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/10 00:15:07 (permalink)
0
I have used the EEPROM in the 16F18855, and used the eeprom_read(), and eeprom_write() inbuilr functions, but they are unavailable in the V1.45 compiler, but are again available in the V2.05 compiler. (as I understood it anyway) I looked for where I read that, didn't find exactly what I was looking for, but, did find this in the 16F18456 datasheet
"13.4.3 NVMREG Write to EEPROM
Writing to the EEPROM is accomplished by the following steps:
1. Set the NVMREGS and WREN bits of the NVMCON1 register.
2. Write the desired address (address +7000h) into the NVMADRH:NVMADRL register pair.
3. Perform the unlock sequence as described in the “NVM Unlock Sequence” section.
A single EEPROM byte is written with NVMDATA. The operation includes an implicit erase cycle for that
byte (it is not necessary to set the FREE bit), and requires many instruction cycles to finish. CPU
execution continues in parallel and, when complete, WR is cleared by hardware, NVMIF is set, and an
interrupt will occur if NVMIE is also set. Software must poll the WR bit to determine when writing is
complete, or wait for the interrupt to occur. WREN will remain unchanged. Once the EEPROM write
operation begins, clearing the WR bit will have no effect; the operation will run to completion.
Related Links
13.4.2  NVM Unlock Sequence
13.4.4  NVMREG Erase of Program Memory"
 
Which is how I went about writing to the EEPROM. I originally created the project with 2.05 compiler, and used the Microchip provided EEPROM read/write built-in functions, but, when I dropped back to 1.45, the compiler would not recognize the EEPROM functions. (I am pretty sure I read somewhere they had been removed for this processor family, so, I went to the datasheet to figure how to read/write.)
 
 
OK, I went and read the section of the user manual you referenced, and have to admit, I had absolutely no idea of the options available with eeprom. I am not sure I understand the EEPROM qualifier, but it looks like you use it to write to EEPROM at the programming stage?  It seems as if you do not provide an address to write to, so, does the compiler just stack them in in the order you declare them?
 
I have been using the following:
4.5.5.3 EEPROM ACCESS FUNCTIONS
The library functions eeprom_read() and eeprom_write(), can be called to read from, and write to, the EEPROM during program execution.These functions are available for all Mid-range devices that implement EEPROM (described in Section “eeprom_read” and Section “eeprom_write”).
 
but, as I said earlier, these functions were not recognized by the compiler  in V1.45.
#5
ric
Super Member
  • Total Posts : 23185
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/10 06:38:40 (permalink)
+1 (1)
davez
...
OK, I went and read the section of the user manual you referenced, and have to admit, I had absolutely no idea of the options available with eeprom. I am not sure I understand the EEPROM qualifier, but it looks like you use it to write to EEPROM at the programming stage?

No. As I said, they behave the same as any other variable, just in eeprom.
You CAN set an initial value, which will be placed into the chip at the program stage, but you can also read and write the value in a running program. Writes will be slower than RAM, but apart from that it behaves just the same.

It seems as if you do not provide an address to write to, so, does the compiler just stack them in in the order you declare them?

I think so.
If you need manual control of locations, you could just declare the whole lot as a 256 byte array.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#6
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/10 13:17:32 (permalink)
0
ric
Please post a small, complete program that demonstrates the issue.
 


Ok, so, it appears as tho I am an idiot! I was trying to re-create the problem on a smaller scale, as requested, and it appears as tho I do not know how to use pointers correctly. (I have always used global vars for data that needed to be passed between modules, but was trying to use pointers, & must not quite understand them. (The pointers seemed to work fine, but were apparently causing this "Static" problem, as all seems to work fine once I went back to using globals)
Which, I still need to thank Ric for his help, as I learned a few more things, and wouldn't have likely figured out what was going on, without his prompting.
#7
ric
Super Member
  • Total Posts : 23185
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/10 13:21:04 (permalink) ☼ Best Answerby davez 2019/07/10 16:36:38
+2 (2)
"Wild pointers" was my first thought when you mentioned variables getting corrupted.
Pointers can be very powerful, so it is worth your while to find out how to use them right.
See if you can determine which one was causing the problem. My guess is you have been using  pointer that has never been initialised, so will be pointing to address zero.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#8
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/10 15:25:07 (permalink)
0
So, I tried to write to the EEPROM space using the following:

#define write_eeprom

#ifdef write_eeprom

eeprom uint8_t pitSetpoint = 230;

#else

#define pitSetpoint         read8bit(parameters[0])            // Pit Temperature setpoint EEPROM Address "offset" value

#endif

 
and got: main.c:15: warning: (1479) EEPROM data not supported by this device
 
I did some more reading, and aslo tried   __eeprom uint8_t pitSetpoint = 0x00; , still got data not supported by this device
 
I also tried using the __EEPROM_DATA() macro, & the eeprom_write function, none of these seem to be available in the 1.45 compiler. I had other issues with 2.05 compiler, that might be cured now with figuring out the pointer issue, so, I will try to see if the eeprom stuff works in 2.05.
 
Once again, thanks
#9
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/10 16:33:59 (permalink)
0
So, with the 2.05 compiler, I used:
 

#define write_eeprom

#ifdef write_eeprom

__EEPROM_DATA(0x00,0xE6,0x00,0xCB,0xCA,0xC0,0x05,0x04);
__EEPROM_DATA(0x03,0x16,0x64,0x00,0x16,0x1E,0x16,0x00);

#endif

and it now works perfectly for writing the first 16 EEPROM memory locations, so, again, Thanks Ric, would not have found this without your tips.
#10
ric
Super Member
  • Total Posts : 23185
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/10 16:43:19 (permalink)
0
With 2.05, you could also just do
 __eeprom unsigned char my_array[16] = 
 {
    0x00,0xE6,0x00,0xCB,0xCA,0xC0,0x05,0x04,
    0x03,0x16,0x64,0x00,0x16,0x1E,0x16,0x00
 };

 
and access any variable just using
 
myvar = my_array[4];    //read the fifth byte

Which makes eeprom access much tidier.
You haven't mentioned DO you need to have the data stored at specific addresses in the EEPROM, or do you just need some non-volatile storage?

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#11
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/10 20:41:35 (permalink)
0
I need the user to be able to adjust EEPROM variables to the user's preferences, so, not just non-volatile storage.
If I just needed non-volatile storage, would I not just code it into flash? Other than the extra 256 bytes, is there an advantage to using EEPROM over Flash?
#12
ric
Super Member
  • Total Posts : 23185
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/10 20:52:29 (permalink)
+1 (1)
davez
I need the user to be able to adjust EEPROM variables to the user's preferences, so, not just non-volatile storage.

How does the user "adjust" the parameters?
That will answer "do you need precise control over EEPROM addresses" question.
 

If I just needed non-volatile storage, would I not just code it into flash? Other than the extra 256 bytes, is there an advantage to using EEPROM over Flash?

EEPROM can be changed a byte at a time. FLASH has to have an entire row erased first before you can program.
(That's 32 words in your device, so if you need to change one, you have to read all of them into a RAM buffer, erase the FLASH, then write it back with one word changed)
 
As I showed above, XC8 is able to place variables directly in EEPROM and access them like any other variables. (Read and write)
"Const" variables can be placed in FLASH, but cannot be written using normal C statements, you have to do it via the NVM registers.
 
An EEPROM write can take place while your code is running. Writing to FLASH stalls the PIC while the write happens.
It depends upon your application if this matters or not.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#13
mlp
boots too small
  • Total Posts : 776
  • Reward points : 0
  • Joined: 2012/09/10 15:12:07
  • Location: previously Microchip XC8 team
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/14 21:31:49 (permalink)
0
ric
pointer that has never been initialised, so will might be pointing to address zero.

Fixed that for you.

Mark (this opinion available for hire)
#14
ric
Super Member
  • Total Posts : 23185
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/14 21:46:14 (permalink)
0
Fair point. I was thinking of a global variable, but if it's an auto one, it could have anything in it.
However, if it's an auto variable it will also generate a "1257" warning if it's used without being initialised.
 

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#15
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/17 23:29:13 (permalink)
0
So, I have actually finally figured out what my problem was! It was not my pointers at all, the problem consistently appears when I use sprintf to display both an eeprom variable, and an auto variable, in the same statement.
Example: Var x is an auto variable, variable z is read from eeprom. (z is "define z eeprom_read(0x02)  )
the statement
  sprintf(buffer1," Temp 1: %05d   Setpoint 1: %05d ", x, z);

will create the problem every time.
while the two statements,
  sprintf(buffer1,"Temp 1: %05d  ", x);

and
sprintf(buffer1,"  Setpoint 1: %05d  ", z); 

works fine.
Is this expected behavior? Or, have I indeed stumbled across a problem with this device?
 
post edited by davez - 2019/07/17 23:36:56
#16
ric
Super Member
  • Total Posts : 23185
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/17 23:36:52 (permalink)
0
George will be happy/relieved ;)
How are "x" and "z" defined?
(I really would recommend you avoid single letter variable names. Much nicer to other people reading your code to use meaningful names, and it makes it easier to search for every reference to that variable.)

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#17
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/17 23:47:28 (permalink)
0
 
x is actually defined as: (x is not my var name, it was just a convienient value to use, rather than pitTemperature)
#define pitTemperature  tempArray[0]                                   // Pit temperature measurement

 
and z is defined as: (also, z is not the var name I used)
#define pitSetpoint        eeprom_read_16(parameters[0])       // Pit Temperature setpoint EEPROM Address "offset" value

 
tempArray[] is defined as:
 uint16_t tempArray[] = {50,50,50,50};

 
And, parameters[] , is the address offset in eeprom space.
 
And, who is George?? Inside joke? or??
post edited by davez - 2019/07/17 23:53:35
#18
ric
Super Member
  • Total Posts : 23185
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/18 00:02:59 (permalink)
0
davez
 and, who is George?? Inside joke? or??

Sorry, I confused this topic and a parallel one also talking about flash/eeprom access on an enhanced PIC16F chip at https://www.microchip.com/forums/m1105412.aspx
George is GeorgePauley, a Microchip employee who is very involved with the MPLAB simulator, which was called into question in that topic.

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#19
davez
Starting Member
  • Total Posts : 32
  • Reward points : 0
  • Joined: 2015/12/11 01:04:29
  • Location: 0
  • Status: offline
Re: Anyone using the PIC16F18456? Does not seem to work correctly? 2019/07/18 00:14:56 (permalink)
0
So, did I do something wrong with the sprintf function, by writing an auto and an eeprom variable in the same statement, or is there something not right with this processor? (I usually never use sprintf to display numbers, so, am not very familiar with its intricacies)
 
post edited by davez - 2019/07/18 09:41:43
#20
Page: 12 > Showing page 1 of 2
Jump to:
© 2019 APG vNext Commercial Version 4.5