CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

16F17115-EEPROM read/write strange behaviour? SOLVED(workar)

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
pet007



Joined: 25 Jan 2023
Posts: 19

View user's profile Send private message

16F17115-EEPROM read/write strange behaviour? SOLVED(workar)
PostPosted: Fri Sep 22, 2023 1:08 am     Reply with quote

Hi, there is something wrong with EEPROM read/write on this MCU
So very simple code : (Compiler 5.115d)

When the line "h_byte = read_eeprom(0x0);" is skipped, RS232 terminal is returning : EEPROM byte = 127 . It's correct, when I let the compiler read from EEPROM adr = 0, it shows only '5' (value stored in EEPROM 0x0 is read ok but printf doens't work correctly anymore/ (see pic bellow).
Please any suggestions? Thank.
Edit: here is using SW RS232.

Code:

main.h
#include <16F17115.h>
#device ADC=12

#rom 0xF000 = {5,2}            // write to EEPROM
//#rom getenv("EEPROM_ADDRESS")={1,2}

#FUSES RSTOSC_HFINTRC_16MHZ     //On Power-up clock running from HFINTRC at 32 MHz
#FUSES CKS                      //Clock Switching Enabled
#FUSES ANALOGRANGE_HIGH         //Internal analog systems are calibrated for operation between Vdd = 2.3V - 5.5V
#FUSES FCMEN                    //Fail-safe clock monitor enabled
#FUSES PUT_64MS                 //Power-Up timer set to 64ms
#FUSES NOBROWNOUT               //No brownout reset
#FUSES NODACAUTO                //DAC Buffer reference range is determined by the REFRNG bit of DACxCON
#FUSES BORV19                   //Brownout reset at 1.9V
#FUSES PPS1WAY                  //Allows only one reconfiguration of peripheral pins
#FUSES STVREN                   //Stack fu ll/underflow will cause reset
#FUSES WDTSW                    //Watch Dog Timer Postscale settable in software
#FUSES WDT_SW                   //Watch Dog Timer setgtable in SW / MEP rucne
#FUSES WDTWIN_SW                //Watchdog Window is settable in software
#FUSES WDTCLK_SW                //WDT clock source settable in software
#FUSES BBSIZ512                 //Boot block size 512 bytes
#FUSES NOCPD                    //No EE protection
#FUSES NOMCLR

#use delay(internal=16MHz) //,restart_wdt)

#use FIXED_IO( A_outputs=PIN_A2)
#use standard_io(A)           
#use rs232(baud=19200,parity=N,xmit=PIN_A5,bits=8,FORCE_SW)

main.c

#include <main.h>
unsigned int8  h_byte=0;
 
void main()

   setup_adc_ports(sAN5, VSS_VDD);
   setup_adc(ADC_CLOCK_INTERNAL | ADC_TAD_MUL_64 |
  ADC_AVERAGE_MODE | ADC_THRESHOLD_INT_DISABLED |
  ADC_LOW_PASS_FILTER_MODE );
   set_adc_channel(4);   
   setup_timer_1(T1_INTERNAL|T1_DIV_BY_2);     
====================================================== //
   delay_ms(10);
   
    h_byte = 127;
    h_byte = read_eeprom(0x0);
  // u16_temp = make16(h_byte,l_byte);

   while(TRUE){    // loop for test only
      printf("EEPROM byte = %u \r\n", h_byte);
      delay_ms(1000);
   }
}

[img]https://k00.fr/16F17115_eeprom_behav[/img]


Last edited by pet007 on Fri Sep 22, 2023 2:20 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Fri Sep 22, 2023 2:05 am     Reply with quote

So, what you are actually seeing, is that the read of the constant string
"EEPROM byte =" is not happening after the read from the EEPROM.

I think I know what is happening. Try changing as:
Code:

#bit NVMREGS=getenv("bit:NVMREGS")

void main()
{
   setup_adc_ports(sAN5, VSS_VDD);
   setup_adc(ADC_CLOCK_INTERNAL | ADC_TAD_MUL_64 |
   ADC_AVERAGE_MODE | ADC_THRESHOLD_INT_DISABLED |
   ADC_LOW_PASS_FILTER_MODE );
   set_adc_channel(4);   
   setup_timer_1(T1_INTERNAL|T1_DIV_BY_2);     

   delay_ms(10);
   
   h_byte = 127;
   h_byte = read_eeprom(0x0);
   NVMREGS=0; //Turn back to data memory
  // u16_temp = make16(h_byte,l_byte);

   while(TRUE)
   {    // loop for test only
      printf("EEPROM byte = %u \r\n", h_byte);
      delay_ms(1000);
   }
}


I'll report this to CCS. The NVM access is used to read this string, and
also to read from the data memory. The read_EEPROM routine, is leaving
the NVMREGS bit set, which tells these registers that access to the
higher stuff in the data memory is wanted, not the normal ROM.
What I've posted turns this off.
pet007



Joined: 25 Jan 2023
Posts: 19

View user's profile Send private message

PostPosted: Fri Sep 22, 2023 2:17 am     Reply with quote

Thanks a lot, this was the issue. Yes, yesterday evening I've starting to read PDF about NVM / FSR access to EEPROM on this type of micro. It's a news for me on this small (but powerfull) 16F171xxx family.

Edit: (listing that's confirmating that issue)
Code:

...................    h_byte = read_eeprom(0x0);
0124:  MOVLB  39
0125:  CLRF   0C
0126:  MOVLW  70
0127:  MOVWF  0D
0128:  BSF    10.6
0129:  BSF    10.0
012A:  MOVF   0E,W
012B:  MOVLB  00
012C:  MOVWF  2E
....................    NVMREGS = 0;
012D:  MOVLB  39
012E:  BCF    10.6
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Fri Sep 22, 2023 3:57 am     Reply with quote

Yes, though they could clear it in the string data read code instead.
If you look, they don't. Not sure really which is the better way to fix it.
Explicitly clear it when it must be clear, or clear it after you set it?
Which they do will be a question for them to fix!...
I went and browsed the code thinking 'what could the read_eeprom code
change', spotted this. Then looked through the string data code and realised
this didn't clear it, so the code there would stop talking to the user ROM.

At least it is an easy fix for now, and hopefully they will fix it very quickly.
Only chips that have the EEPROM accessed like this will have the problem,
but probably most of these will have this issue..... Sad
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Mon Sep 25, 2023 9:10 am     Reply with quote

They have included the fix for this in a new compiler release. Due out
later this week. Very Happy
pet007



Joined: 25 Jan 2023
Posts: 19

View user's profile Send private message

PostPosted: Mon Sep 25, 2023 11:15 am     Reply with quote

Good job Smile
pet007



Joined: 25 Jan 2023
Posts: 19

View user's profile Send private message

PostPosted: Fri Oct 06, 2023 4:35 am     Reply with quote

Anyway, please is the new announced version already released or it isn't ? Thanks (my compiler still doesn't find any new updates...) Thanks.
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Fri Oct 06, 2023 5:24 am     Reply with quote

Not seen it yet. They said 'end of the week'. Suspect it'll be late Friday,
or get delayed to Monday.

Did come out late Friday (UK time), so Friday morning in the States.
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Thu Oct 12, 2023 2:26 am     Reply with quote

Can confirm 5.116 fixes this. Smile
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group