Problems with read/write pseudo array variables in sram_23k256.jal library

[PDSACAA]

Hello All
I am working with 23k256 sram and seem to have found problems with
23k256_sram.jal include library procedures while executing
16F877a_23k256.jal sample.

In general all seems to work in principle , however:-
when using the word and dword read/write array pseudo variable
procedures with large data values (I am afraid I cannot be more
specific) say 0xDDFF in the case of word or 0xAABBCCDD in the case of
dword, problems seem to occur.

i.e. data seems to be either written to sram incorrectly or
incorrectly read back again using the array pseudo variables. I have
used alternative single byte read calls supplied in sram_23k256.jal to
examine consecutive sram addresses and whereas things appear fine with
most data values with other large data values problems show up. For
example the 16F877a_23k256.jal sample as coded in the library I do not
think gives the expected results.

The use of pseudo-variable arrays was discussed in jallist recently
with some reservations, however Kyle confirmed that their use was now
fully supported by the compiler.
The code in 16F877a_23k256.jal sample as distributed only used
constant values for the pseudo array indexes. I tried using assigned
(word) variables for indexes but it didn't make any difference (no
surprise there!!)

I have downloaded the 23k256_sram.jal library module supplied in svn/
trunk/include/external/storage/ram assuming that this is the latest
version. I am correct in this or will there be a later version?

I have sample code (which to be honest is really no more than a cut
down version of 16F877a_23k256.jal ) which shows up problems but I am
not sure how to submit this to JALLIB for examination. How does one
post code to JALLIB forum? Does one just include it in the post?

I have examined the code in the pseudo variable procedures in
23k256_sram.jal and it looks good to me. There are some subtle lines
of code that I find confusing but which I do not think can the cause
of the problem.

One of these is the repeated use of :-

var byte addr[4] at address

where address is a word value and we clearly only require access to
the 2 bytes addr[0] and addr[1]. Presumably addr[2] and addr[3] just
point to other non-relevant storage locations but why is this done? I
am obviously missing something here!

Can I also mention that Tutorial p104 says "23k256 uses SPI mode
1,1" ,it dosen't it uses mode 0,0 as borne out by code in
16F877a_23k256.jal.
as provided by the JAL distribution.

It also appears that the code in the tutorial differs from distributed
16F877a_23k256.jal to which it refers. This is not necessarily a
problem but the references on p101 and p104 to "const bit
SRAM_23K256_ALWAYS_SET_SPI_MODE = TRUE" are confusing when in fact
this is not the way that the SPI mode for the 23k256 is asserted in
16F877a_23k256.jal and other samples. I just think this is confusing
for the novice and think the reference would be better removed.

Can I ask members to check these issues and confirm or reject these
problems I experience?

Many Thanks
Dave Paxton

[mattschinkel]

Hi,

Please post your full sample code here, I'll have a look. The word and dword procedures haven't been used much, so I wouldn't be surprised if there may be a bug in there somewhere. I assume the sample is working for you? It does have a word/dword test in it.

The code on justanotherlanguage.org tutorial should still be valid, but use the sample in the package or on SVN. SVN is always the newest.

I believe you can use either SPI mode 00 or 11 with 23k256.  

> var byte addr[4] at address

If the top bytes of this array are not used, the compiler will ignore them.


Matt.

[Rob Hamerling]

Hi Dave

On 30-08-12 15:51, PDSACAA wrote:

> How does one post code to JALLIB forum? Does one just include it in the post?

This forum allows you to attach a file to your message (and passes it to
other readers!). Attaching a file is not only easier for you than
copy-and-paste into the msg body, it is also easier for readers to copy
your code. So we're looking forward....

Regards, Rob.

--
R. Hamerling, Netherlands --- http://www.robh.nl

[PDSACAA]

Matt/Rob

Thanks for feedback its very encouraging when one is stumped for ideas.

Have enclosed code designed to test the pseudo-array variable procedures supplied in sram_23k256.jal library.

This code is clearly a cut down/modified version of Matt's 16F877a_23k256.jal in the library.

When I run this I observe the following:-

sram_23k256_byte[] read and write ok irrespective of data written or read

sram_23k256_word[] write ok irrespective of data written

sram_23k256_word[] read can incorrectly read large values  that have been written correctly

sram_23k256_dword[] write ok with many values of data

sram_23k256_dword[] write can incorrectly write large values of data 

sram_23k256_dword[] read can incorrectly read large values  that have been written correctly or incorrectly.

 

Incidently all these data read/writes are within page0 but since the 23k256 is put in sequential mode early on in in the code

a read/write past a page boundary should not be an issue anyway

Just for record I tried the 23k256 code with SPI mode forced 1,1 but got nowhere.

 

I keep looking at the 23k256.jal code but honestly cannot see how the code could produce this effect.

I would worry more that this is a compiler thing but I am not qualified to comment further.

Also tried with 18LF4620, but experienced same problems.

 Kind Regards

Dave

[PDSACAA]

Matt/Rob

I am a bit worried I might be wasting your time on this problem in the sense that I have just been trying a change to
the clock speed and PIC device in order to troubleshoot this but when doing so the read/write errors change.
Some errors are still there but some seem resolved.

This seems strange to me and difficult to attribute to coding problems. I am using the resistor divider components
as shown in the tutorial to get the 3.3V signals from the PIC to the 23k256 but I have read elsewhere
 (in the sd card documentation?) that resistor divider networks on the clock line can cause problems.

I got to thinking (probably rubbish) but large data values means writing/reading a lot of consecutive one's and I
wondered if this was significant. I have the components (74HCT08 etc) to do the signal conversion but have not used
them yet. Do you think I should do this before I ask you to spend any more time on this?

Regards
Dave

[mattschinkel]

Please try the 74HCT08. The resistor divider should work as well, but 74HCT08 will give you better signals.

Matt.

[PDSACAA]

Matt
I knocked out a board using the 74HCT08 logic IC and a LD1117V33 voltage regulator to guarantee a 3.3V supply voltage to
the IC.
I jumpered together the pair of logic input pins on each of the 4 IC gates and fed the PIC outputs CLK,SDO and SS
to 3 of these IC input pairs. Fed the 3 IC outputs to the 28K256. The 28k256 SO line went straight to PIC SDI pin as before and as
per tutorial schematic.
I checked all of the IC output voltage levels using simple program to raise or lower PIC pins. These seemed ok dropping to 0v
low or rising to 3.68V high.

Unfortunately when running sample program to read/write 28k256 via the 74HCT08, I get nothing but FF's.
I have checked, checked and rechecked wiring but can't find anything wrong.

I take it that it goes without saying that the 74HCT08 can switch at the clock speeds the SPI routines throw at it?
I dropped the CLK speed down to the minimum but this showed no difference.
Have you got any ideas where I might have slipped up?

At least the resistor divider network worked up to a point!!

Regards
Dave

[mattschinkel]

Sorry, I've been to busy to test anything.

If your getting 0xFF there must be something wrong with the hardware or your connections. You do not need to do any level conversion for the SDO line (signal out of 235254 to the PIC).

74HCT08 will work, I've done it in the past.

Matt.

[PDSACAA]

Matt
Try as I may I cannot solve my problems attempting to use the 74HTC08 but I will keep trying.

Can I ask you a question regarding the resistor dividor networks shown in the tutorial schematic illustrating the use of the 23k256 sram.
Two of the SPI lines ( SS and SDO) use 1.5k/3.3k resistors to step down the voltage but for the CLK line you indicate 470/2k.
Why does this divider network differ from the other two lines. Understanding this may just help me to see what I have done wrong using the
74HTC08.

As you have probably guessed my knowledge is weak on the electronics side of things.

Kind Regards
Dave Paxton

[mattschinkel]

I did that to allow more current on the clock line. I don't quite remember the reason for more current.

Maybe test your 74HTC08 or try another 23k256. If it works for me, it should work for you.

Is your power supply stable? Maybe you need more capacitors on your supply.

Matt.

[Joep Suijs]

More current allows for faster signals.

Note that not only the current has increased, but also the voltage, due to the different ratio. With the values presented, it is way above the 'absolute maximum ratings' from the datasheet, so the chip might be damaged.

Use 1k/2k instead and try a new chip...

Joep

Op dinsdag 11 september 2012 schreef mattschinkel (mattsc...@hotmail.com) het volgende:

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/RScH_oJng40J.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

[PDSACAA]

Matt/Joep
Thanks for feedback, I will take this onboard.
To be honest I have not had, and still do not have any real trouble using the divider networks as shown.
in the tutorial other than the problems for which I started this post, namely that of  reading/writing large data byte values.
So I do not think the 23k256 is damaged but I now have another which I can try.

However I will try the PSU capacitor idea and the 1k/2k divider to see if this gets rid of the anomaly.
If so I might just stop there.

The frustrating thing is the 74HCT08 ( and a replacement I tried) which appear to  work ok as an alternative to the divider networks
in response to individual raising or lowering of inputs i.e it provides 0v - 3.3v (ish) outputs.
However it just does not seem to do the job when hammered by the SPI pin changes.
Clearly there are many references to the recommended use of the device as a 5V/3/3V level shifter on the web so it has to be
down to my circuit wiring.!!!

I have borrowed an oscilloscope from my son but tell the truth with my knowledge it is probably a dangerous thing!!

Thanks for your help
Kind Regards
Dave

[PDSACAA]

Matt/Joep
A result!!

Changed the CLK resistor network to 1k/2.2k  (didn’t have 2k don’t ask why)

Assuming PIC output level of 5V, divider would give 3.44V (ish) which was within  23k256  spec of  Vcc (3.3V )  + 0.3V max. input.

Obtained perfect results no problems reading/writing large byte values. - yippee!!

Showed that 23k256 had not appeared to have suffered any damage from my fumbling.

Think I will stop there and call a halt on the 74HTC08 alternative method for now.

 Looks as though comment by Joep "larger current faster signals" did the trick.

Where would one look on the 23k256 data sheet to assess the clock current sensitivity?

If you find out why will you let me know?

Thanks for help with this

Kind Regards

Dave

 

[Joep Suijs]

Hi Dave,

Good to hear it works.
First of all: the PSU decoupling (100n close to each chip) is
mandatory for digital circuits to work reliable.

The input current of 23k246 can be neglected. Speed is determined by
the feed resistance and the capacity of the circuit (that is: input
capacity of the chip, but also of traces). Long wires do add extra
capacity (and induction, to make it even worse).
It is hard to predict the real capacity and thus the max resistance
allowed for a certain speed. In practice, an oscilloscope can be used
to determine if the signal is good enough.

Regards,
Joep

2012/9/11 PDSACAA <da...@paxton.me.uk>:

> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/jallib/-/eA8MlKwUm30J.

[mattschinkel]

Sorry for the bad schematic (wrong resistors) I'll get this fixed in the tutorial. It might also be a good idea to try getting away from 5v circuits all together so you don't need those resistors at all.

 

If you ever need more the 2 SPI devices, you'll need that 74HCT08 or another chip to allow you to have more connections.

 

I'm glad it's working for you now :)