• MATLAB
  • i2c block not working as expected
2020/11/24 16:37:22
Poley
Hi all, I have been using the i2c blocks perfectly fine until I needed to implement something that wound set a range of bytes to 0. I am using a dsPIC33EV256GM106.
 
I have no idea why it is not working, I seem to have tried every variation I can think of. 
 
I have attached one that is working which contains 6 different uint8's that I am writing to EEPROM starting at 0xFFC0 and the second should write a uint8 '0' to 7 bytes starting at 0x1FFC. This just doesn't set the values to 0, they are staying at FF as they have never been written to, am I doing anything obviously wrong? 
 
Thanks in advance for the help!

Attached Image(s)

2020/11/24 17:39:00
ric
What EEPROM device are you writing to?
The second example is crossing over an 0x100 page in the middle of the write, which could be a problem on some devices.
 
2020/11/25 02:21:40
Lubin
Hi Poley,
 
Few inputs:
The delay at the start of the I2C sequence is to avoid: The I2C sequence set is driven through interrupt. Any delay within the sequence will block the interrupt and thus any other thread as well. If a delay is required between two I2C component addresses, It should be really small (few us). usually this is not required anyway. 
setting the I2C block sampling time to 0.01 second will provide a delay of 0.01s - the I2C transfert time.
 
 
With EEPROM write, please ensure that your are not overstressing the EEPROM max number of writing. The I2C block writting to the EEPROM might probably be in a conditionally executed subsystem.
 
The I2C block propose an additional output which let you know if the sequence executed completely, receiving all required ACK from the addresse component. You might check this output.
If you have a scope, please check the I2C lines to check the transaction. Maybe the problem is how the EEPROM is addressed as mentionned by Ric above.
 
 
2020/11/25 02:40:46
Poley
Hi Lubin
 
Thanks for the reply.
 
The delay was only in as I was just trying different things to see if it worked, it is helpful to know why not to use them though, thanks.
 
The EEPROM Write is in an enabled subsytem that runs for 200ms. If I combine both of those I showed into the same write then it still only does the FFC0 address and not the ones following the 1FFC addresses it's very strange. I have just tried reporting ACK and it says it has completed but when I read the bytes after they haven't changed. 
 
Here is my read block alongside the write block that isn't working. The weird thing is the first 4 bytes on the write work if the value is over 3 but not below, and the following 3 don't change from FF.
 
Scope shows everything is ok as it is writing fine to some bytes like the ones shown for the checks in first post.
 
Thanks for the help

Attached Image(s)

2020/11/25 03:13:20
Lubin
Hi Poley,
 
The problem seems not related to our I2C MPLAB block but to the way the component is addressed.
 
I find in the EEPROM doc a note which confirm Ric's idea
in DS21754M, page 10, Note:
"Page write operations are limited to writing bytes within a single physical page, regardless of the number of bytes actually being written. Physical page boundaries start at addresses that are integer multiples of the page buffer size (or ‘page size’) and end at addresses that are integer multiples of [page size – 1]. If a Page Write command attempts to write across a physical page boundary, the result is that the data wraps around to the beginning of the current page (overwriting data previously stored there), instead of being written to the next page as might be expected. It is therefore necessary for the application software to prevent page write operations that would attempt to cross a page boundary."
2020/11/25 03:25:36
ric
Poley
This is the EEPROM I am using: 
 
https://www.mouser.co.uk/ProductDetail/Microchip-Technology/24FC512-I-SM?qs=Q%2Fw7XRh99in74VMVq2d3zA%3D%3D

Thanks. You really should have mentioned this in the first post.
Have a read of section "6.2 Page Write" in that datasheet, and you will see that for that device, the page size is 128 bytes (0x80), and you should NOT try to write over a page boundary in one transaction.
2020/11/25 03:31:35
Poley
Yeah that makes sense, thank you! Completely missed that in the datasheet!
 
If a page is 0x80 then is what I have attached the correct way to address the new 0x80 page and to fill it with 0's?
 
Thanks 

Attached Image(s)

2020/11/25 03:43:10
Lubin
Hi Poley,
 
Regarding the sequence set in your last block. not sure it works.
There is a minimum time for the page beeing written (I think it's 5ms ; to be checked).
 
Here you could add the 5ms delay between the two write sequence. But it's even better to use two blocks and a sample time shift:
Block 1 with a sampling time of [0.01 0], and block 2 with a sampling time of [0.01 0.005].
Doing so, you get two block executing at every 10ms, but shifted by 5ms (with some jitter).
 
Lubin
 
 
2020/11/25 03:46:35
Poley
That's great, thank you!
 
Is this also the case with read? How do I start reading from a different byte efficiently?
 
Here is how I read from 2 different places currently

Attached Image(s)

12
© 2021 APG vNext Commercial Version 4.5

Use My Existing Forum Account