| View previous topic :: View next topic |
| Author |
Message |
pet007
Joined: 25 Jan 2023
Posts: 21
|
| 16F17115-EEPROM read/write strange behaviour? SOLVED(workar) |
 Posted: Fri Sep 22, 2023 1:08 am |
 |
|
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: 19504
|
|
| Posted: Fri Sep 22, 2023 2:05 am |
|
|
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: 21
|
|
| Posted: Fri Sep 22, 2023 2:17 am |
|
|
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: 19504
|
|
| Posted: Fri Sep 22, 2023 3:57 am |
|
|
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.....  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Mon Sep 25, 2023 9:10 am |
|
|
They have included the fix for this in a new compiler release. Due out
later this week.  |
|
|
pet007
Joined: 25 Jan 2023
Posts: 21
|
|
| Posted: Mon Sep 25, 2023 11:15 am |
|
|
Good job  |
|
|
pet007
Joined: 25 Jan 2023
Posts: 21
|
|
| Posted: Fri Oct 06, 2023 4:35 am |
|
|
| 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: 19504
|
|
| Posted: Fri Oct 06, 2023 5:24 am |
|
|
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: 19504
|
|
| Posted: Thu Oct 12, 2023 2:26 am |
|
|
| Can confirm 5.116 fixes this. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
