PIC18F27J53 and a I2C EEPROM M24128B

[mbristol78]

Hi,

I have trouble interfacing a PIC18F27J53 and an I2C EEPROM M24128B.

In the attached pic_eeprom.pdsprj
The oscilloscope shows that the PIC seems to send good data on its I2C module.
But I have a few bugs/questions:
1 - In the code, eeprom_M24128.c line 93, if I dereference and use u8_data, passed as an argument to the function, I seem to have no more printf, line 100 and 108, so something goes wrong there,
if I hardcode the value in SSP1BUFF, the printf are seen on the terminal.
2 - Looking at the oscilloscope, the ack from the slave seems much wider than the ack that can be seen in the simulation of the other attached project "debugger_eeprom.pdsprj"
3 - the other project "debugger_eeprom", the writing occurs fine (I can see the final 0x12 written at address 0x00)
4 - In the pic_eeprom.pdsprj, if I put the resistors as DIGITAL, nothing runs and I have a log error saying the PIC is held in rst, any explanation?

Base on the file size, I don't think the code is included in the pdsprj file so I have added it separately.

Thanks for help

[Ettore]

1. Such the item needs to be better investigated as if a buffer pointer is passed onto that function the data are not written in the eeprom at all and it looks as though this affects the printf serial buffer as well.

I have modified your code by adding some other functions like WriteI2C(), ReadI2C(), IdleI2C(), NotAckI2C() and AckI2C() from Microchip standard libraries, that make the I2C sequence more readable. I pass the data writing to and reading from into a couple of global arrays, eeprom_wValue and eeprom_rValue. Looking at the variable window when simulation ends you should find out trhe 5 values into the eeprom and into the write and read buffers. The modified Proteus project and the imulation screen shot are following:

pic_eeprom.pdsprj

(21.06 KiB) Downloaded 1480 times

Immagine 2024-01-25 174143.jpg (479.32 KiB) Viewed 2158 times

2 & 3. related to previous item 1.

4. As we have already explained in the e-mail we sent on the 18/January, when you don't use standard power terminals (with no POS_3V3 label) you need to ensure that the minimum digital voltage configured into the power rail configurator is greater than 3.5V. Otherwhise the digital voltage is less than the minimum value and this triggers the "PIC is held in rst" message because of $MCLR pins in low condition. This may be avoided if you use standard power rail (VCC) as this is the default power terminal for digital purposes.

Other points.
a) In the code I have added an initial delay of 10ms at start up.
This is done to allows the oscilloscope to trigger the signal and display SDA and SCL traces.

b) The simulator options were set to "Settings for Better Accuracy" which slows down simulation in some cases. Those options must be left to "Default Settings" if not exactly sure what you are doing otherwise.

[Ettore]

Posted wrong file

pic_eeprom.pdsprj

(21.13 KiB) Downloaded 1625 times

[mbristol78]

Hello, thanks for your reply.
I cannot see any changes in your last attached project, the code is missing. Would you be able to send or attach again?
Thanks

[Ettore]

Look at the post above. I have posted the correct file.

[Ettore]

For your convenience I post the code directory as well.

PIC18F27J53_1.zip

(101.94 KiB) Downloaded 1657 times

[mbristol78]

Thank you, I can see it running with your changes.
I will have to dig into the microchip lib as my code has to be multiplatform, but that is not a problem for now.
Thanks again, that should unblock me nicely!

[Ettore]

Ok! At the end of the day I finally found the reason as to why if you pass u8_data as a pointer of the function all weird things happens. (item 1.)
The problem was simply that you didn't use any configuration bits (see PIC18F27J53 datasheet to chapter "Special Features of the CPU"), so the bit XINST in CONFIG1L is set to 1 by default.

As a result the PIC18 is using the "set extension and Indexed Addressing mode", but should the compiler is not supporting this mode or it is not set to compile with these extention enabled it will build object code in legacy mode only. This is exactly the case with XC8 compiler. The simulated PIC18 model, however, expects object code in set extention mode and this is the reason of all odd behaviours you have seen so far!

As you can see it has nothing to do with PIC18 simulator and Proteus as well but with a bug in the user's code.

In order to disable the extension mode you should add the line:

#pragma config WDTEN = OFF, PLLDIV = 1, CFGPLLEN = OFF, STVREN = ON, XINST = OFF

Please note the last setting XINST = OFF; that's the config bit I was talking of.
You can add the above line conveniently after the #include <xc.h> in main.c

Also for your convenience I add the code cleaned and modified to use function pointer to pass any lenght of data.
The length is defined as MAX_BUF.

PIC18F27J53_1.zip

(127.95 KiB) Downloaded 1452 times

[mbristol78]

oh I see, well done to find that out.
Indeed as I was struggling I was starting from scratch and forgot to set the configuration bits.

Maybe that should be another thread but I'll ask here,
Proteus seems to use xc8.exe whereas MPLAB uses xc8-cc.exe
The Proteus gets overwritten every time (is there a way not to?) so I can't change it there. I have tried to physically rename the xc8-cc to xc8 but that is not a nice solution and not sure it fully works yet.
The reason for using the same compiler version would make the transfer MPLAB to Proteus easier, as the CC flags would be the same.
As for an example, xc8-cc takes -mcpu whereas xc8 take -chip, and other flags.
More to this, in Proteus it seems like you can only add predefined flags from the list, so if you want to add -mcpu you need to add a blank line and pass the flag and its value in the value field. All of this would be easier if I could use the same compiler, if at least I can modify the Proteus makefile, or point to another one, is that possible?

Thanks

[Andrew]

Hello,

Unfortunately it is not possible to change Makefile. It is generated before compilation according to the rules, described in the compiler configuration file. For this compiler, it is "C:\ProgramData\Labcenter Electronics\Proteus 8 Professional\VSM Studio\compilers\xc8.xml".

I will try to make it compatible with the latest version of XC8 compiler. However it is very frustrating that Microchip are changing binary names and compilation flags, as it makes it incompatible with the previous version. So I guess it will require a new configuration file instead of modifying the existing one.

Best regards,
Andrew

[mbristol78]

Hello,

I have hacked the xc8.xml and I can build using xc8-cc.exe.
Roughly, I have deleted some lines and passed all my compiler and linker flags in the CMDLINE.
There is probably a cleaner way to do it, having option lines etc. but I just wanted to see quickly if that would work.
The little drawback is that it won't build twice in a row, (I can't remember which error is generated) unless I delete the object files from the directory. Since the clean recipe cannot be changed in the makefile, I use the POSTPROCESS CMDLINE at the end of the linker command to delete all object files. In a longer program that will force every source file to be rebuilt, but doesn't matter much to me at this point.
The linked .cof can be used to step through each line.

Thanks again for your time.
Regards
Mick