|
|
View previous topic :: View next topic |
Author |
Message |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Wed Mar 29, 2017 10:05 am |
|
|
Pretty much all text books contain errors. Embedded programming ones are well known for it. Some text books contain falsehoods and some even downright lies. Doesn't stop them being useful, nor does the earth stop turning.
Anyway, the philosophy of such things doesn't get you up and running with code, so let's get on with sorting out what might be going on.
Yes, the "driver" is crap. It clearly doesn't work, and I say that not from checking with hardware, but from looking at the datasheet and doing the engineering thing. Be aware that we are NOT CCS. We are just users doing what we can to help each other out, just like you.
There are several issues. First the driver is far from complete. The init routine enables writing and leave it enabled. That's not great, especially is odd stuff happens when the power goes down. Far better to enable and disable writing when needed, or in the case of your C version, arrange the hardware to enable and disable via PE. The "driver" doesn't have any implementation of the disable function, nor indeed of any erase functions or the write all function. It merely implements the most basic three functions, Read, Write and enable write, which it has to do to be able to write.
Also there's no accounting for the limited clock rate range of this IC. At 5V it's limited to 3MHz clock. Now, that's not a problem with your (very slow) 500KHz processor clock, but wouldn't be any good with a much more commonly used 8MHz typical of internal oscillators on PICs and would be hopeless if the PLL was used. Many PICs easy go to 40 or 64MHz. I'm using 24s clocked at 80MHz. The driver would not work for any such setup; there would have to be some slugging of the EEPROM clock by adding nops using delay_cycles(). The driver, however takes no account of clock rate whatever.
I don't think any of that is what is causing your problems however. What might be, and it's just a suspicion based on the datasheet, is that the EEPROM seems to expect a clock pulse BEFORE CS is raised. (Typical SPI, which this ISN'T, would have an active low going CS and the clock would start AFTER enabling CS, which is how the "driver" seems to have been written). The driver doesn't implement this pre-CS clock. That might be causing the problem. However, I cannot see anywhere in the datasheet where it specifies that the pre-pulse must be there; I can only see it in the timing diagrams.
I also notice that the driver doesn't check for the ready signal, though it does wait 11ms after writing. This interface, unlike SPI where busy is usually sense by a read command rather than by a timed, has unclocked pulse on the data line that if you are going to read it, you have to do so at the right time after a write.
So, I suggest you look at this pre-pulse on the clock. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19543
|
|
Posted: Wed Mar 29, 2017 10:20 am |
|
|
That pulse is the 'start bit'. Section 2.1 in the data sheet.
Everything is disabled till that is seen. Rising edge on CLK, with both CS and the data line held high. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Mar 29, 2017 10:29 am |
|
|
To Aileyus,
I made a late addition to my post just before you replied.
You probably didn't see it:
5. I noticed something from your first post. You have LEDs tacked on
the signal lines for the eeprom. I wouldn't do that. You have high-speed
signals and you're loading them down with LEDs. Remove all the LEDs |
|
|
Aileyus
Joined: 23 Mar 2017 Posts: 27
|
|
Posted: Wed Mar 29, 2017 10:37 am |
|
|
It turns out that the clock is low when CS goes high for the EWEN and Read instructions. However, the clock is high and DI is high when CS goes high for the Write instruction. Being that CS is relevant, this is therefore NOT a 3 wire microwire.
I'm very happy that someone wrote the note at the end of section 2.1 in the datasheet. That second paragraph is very confusing without the note.
Last edited by Aileyus on Wed Mar 29, 2017 11:23 am; edited 1 time in total |
|
|
Aileyus
Joined: 23 Mar 2017 Posts: 27
|
|
Posted: Wed Mar 29, 2017 10:42 am |
|
|
Ding, ding, ding. We have a winner!
I corrected the problem with the clock being high when CS went high on write. I set the clock low and then set CS high. Now everything works as expected. I'm reading what I write to the memory.
YAY!!!
Thanks for your patience guys. Good catch. That's pretty subtle (but critical). |
|
|
Aileyus
Joined: 23 Mar 2017 Posts: 27
|
|
Posted: Wed Mar 29, 2017 10:48 am |
|
|
PCM programmer wrote: | To Aileyus,
I made a late addition to my post just before you replied.
You probably didn't see it:
5. I noticed something from your first post. You have LEDs tacked on
the signal lines for the eeprom. I wouldn't do that. You have high-speed
signals and you're loading them down with LEDs. Remove all the LEDs |
I strongly agree and I would never do that in practice. However, this is just the development kit and that is how CCS designed it. It works but we won't be doing that in the real world.
Thanks again all. Now I'll start writing the real code for my application. First thing was to see if I could get all my peripherals working. The EEPROM was the last peripheral. This is a very simple application (it has to be for an analog geezer). |
|
|
|
|
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
|