TheBackShed.com

Forum Index : Microcontroller and PC projects : UNI/O EEPROM Driver

Page 2 of 3

Author

Message

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3282

Posted: 04:39pm 25 Jul 2017

Copy link to clipboard

Print this post

Damn, there must be something wrong.

I will retest but I may have to just give up on the UNI/O chips. They were hard enough to get working in the first place and I spent a lot of time fine tuning the driver to get the best reliability - but it still does not seem good enough. It might explain why these chips have not taken the world by storm.

Geoff

Geoff Graham - http://geoffg.net

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3282

Posted: 02:16am 29 Jul 2017

Copy link to clipboard

Print this post

Due to some brilliant detective work by TassyJim which pointed me in the right direction I believe that I have found (and fixed) the stupid bug which stopped writes from working.

Could you guys please give the attached new driver a run: 2017-07-29_121345_UNIO.zip

(fingers crossed

)

Geoff

Geoff Graham - http://geoffg.net

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6268

Posted: 01:27pm 29 Jul 2017

Copy link to clipboard

Print this post

Not so fast Geoff!

I can see a big improvement but still no joy writing data.

I am trying this

Quote myname$ = "AAAAAAA"
status = UNIO(UNIOpin, 02, &H10, 7, myName$)

I can see the command to write followed by the address
Then there is a '07' byte (length?)followed by 7 'A1' bytes "AAAAAAA" followed by 8 zero bytes. (Filling the write buffer?)

That doesn't agree with my understanding of the datasheet.

This is part of my diagnostic.

Quote C:\Users\Jim\Documents\apps\unio09.ols
Resync
10100000 A0
MAK
SAK
10010110 96
NOMAK
SAK
Resync
10100000 A0
MAK
SAK
01101100 6C
MAK
SAK
00000000 00
MAK
SAK
00010000 10
MAK
SAK
00000111 07
MAK
SAK
01000001 41
MAK
SAK
01000001 41
MAK
SAK
01000001 41
MAK
SAK
01000001 41
MAK
SAK
01000001 41
MAK
SAK
01000001 41
MAK
SAK
01000001 41
MAK
SAK
00000000 00
MAK
SAK
00000000 00
MAK
SAK
00000000 00
MAK
SAK
00000000 00
MAK
SAK
00000000 00
MAK
SAK
00000000 00
MAK
SAK
00000000 00
MAK
SAK
00000000 00
NOMAK
NOSAK
00101010 2A
MAK
SAK
Resync

Resync

I will do some more prodding the beast later today.

Jim

VK7JH
MMedit

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6268

Posted: 02:25pm 29 Jul 2017

Copy link to clipboard

Print this post

Quote myname$ = "AAAAAAA"
status = UNIO(UNIOpin, 04)
PRINT "Write all FF: ";status
status = UNIO(UNIOpin, 01, &H10, 24, NewName$)
PRINT "Read Status: ";status
PRINT LEN(NewName$)
NewName$ = LEFT$(NewName$,24)
PRINT NewName$
status = UNIO(UNIOpin, 02, &H10, 7, myName$)
PRINT "Write string: ";status
status = UNIO(UNIOpin, 01, &H10, 24, NewName$)
PRINT "Read Status: ";status
PRINT LEN(NewName$)
NewName$ = LEFT$(NewName$,24)
PRINT NewName$

Quote > RUN
Write all FF: 1
Read Status: 1
255
��
Write string: 0
Read Status: 1
7
AAAAAAA
>

Write all memory to FF - OK
Read 24 bytes - End up with a string 255 byte long 24 FF's followed by zeros

Write "AAAAAAA" - gives fail but actual write did occur.

Read 24 bytes - End up with a 7 byte string containing the previously written "AAAAAAA" The leading &h07 and trailing zeros have been trimmed.

The actual bytes starting at &h10 are:
7
65
65
65
65
65
65
65
0
0
0
0
0
0
0
0
255

Jim

VK7JH
MMedit

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3282

Posted: 05:11pm 29 Jul 2017

Copy link to clipboard

Print this post

Thanks Jim,

status = UNIO(UNIOpin, 02, &H10, 7, myName$)

should be

status = UNIO(UNIOpin, 02, &H10, 8, myName$)

because you are writing eight bytes (all MMBasic strings have one additional byte for the length - I think that this is mentioned in the doco).

However, your trace has uncovered another bug where the number of bytes to be written within a page was incorrectly calculated - this is why you got the extra zeros written.

But it does not explain why you got a slave negative ACK at the end. I will be some more exploring also.

BTW your logic analyser output is very helpful. My logic analyser has a broken UNI/O function so I have to manually decode the protocol on the oscilloscope - very tedious for manchester encoding.

Geoff

Geoff Graham - http://geoffg.net

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6268

Posted: 06:26pm 29 Jul 2017

Copy link to clipboard

Print this post

I knew I should have read the manual!

I am glad my logic analyser output is of some use. I got sick of trying to hold a bit of paper on the screen to decode the graphics - very difficult with a touch screen, so I wrote the very crude program to decode.
The program has problems with long traces.

I found that writing numbers works OK but has the same problem of writing too much data.

I got a surprise when I did a test and wrote 8 bytes to the first half of a page and read back the full page

Quote 0000003F ?
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000055 U
0000004E N
00000049 I
0000004F O
00000050 P
00000049 I
0000004E N
00000000
000000FF

&h3F is the number I wrote and
UNIOpin is the name of the variable I used for the pin number.
The FF is the start of the next page.

Jim

VK7JH
MMedit

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6268

Posted: 06:35pm 29 Jul 2017

Copy link to clipboard

Print this post

Geoffg said
But it does not explain why you got a slave negative ACK at the end. I will be some more exploring also.

Geoff

I wouldn't put too much faith in my results, especially when it's a long way in, the code is very rough.

Now I have the right length for strings I find that it write first go some of the time, other times I takes 3 or 4 attempts.
It should be OK with numbers and short strings.

This has been an interesting exercise.

Jim

VK7JH
MMedit

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3282

Posted: 08:42pm 29 Jul 2017

Copy link to clipboard

Print this post

Could you try this one: 2017-07-30_063552_UNIO.zip

I have found and fixed the bug that caused too many bytes to be written. Also I hope that I have fixed the issue with writes returning as failed when they have actually succeeded. This last problem is down to Microchip, their specs for the start header setup time (Tss) say 10uS but I have found that 100uS is much more reliable.

Lets hope that this version works (fingers crossed - again)

Geoff

Geoff Graham - http://geoffg.net

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6268

Posted: 09:28pm 29 Jul 2017

Copy link to clipboard

Print this post

This one looks good.
I didn't have any fails with about a dozen writes and the logic analyser doesn't show any repeats with a quick look.

Jim

VK7JH
MMedit

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3282

Posted: 09:54pm 29 Jul 2017

Copy link to clipboard

Print this post

Good news. Is there anyone else who could test this.

If I get a few good results I might declare the driver working!

Geoff

Geoff Graham - http://geoffg.net

drkl

Senior Member

Joined: 18/10/2015
Location: Hungary
Posts: 102

Posted: 11:57pm 29 Jul 2017

Copy link to clipboard

Print this post

Success....

'TEST
'WRITING THE STRING NAME$ WHICH WILL HAVE A MAXIMUM OF 16 CHARACTERS.
'CHIP 11LC160 WITH SUGGESTED
DIM NAME$,NAME1$ AS STRING, STATUS,LAB as INTEGER
NAME$="0123456789ABCDEF"
STATUS=0
LAB=19
DO WHILE STATUS=0
STATUS = UNIO(LAB,04)
LOOP
? "FILLSTATUS=",STATUS
? NAME$
STATUS = UNIO(LAB,02,0,17,NAME$)
? "WRITESTATUS=",STATUS
NAME1$=""
STATUS = UNIO(LAB,01,0,17,NAME1$)
? "READSTATUS=",STATUS
? NAME1$
END

The result:

? mm.ver
5.0404
> run
FILLSTATUS= 1
0123456789ABCDEF
WRITESTATUS= 1
READSTATUS= 1
0123456789ABCDEF
>

I want to make more test, but it seems to be good.

Cheers:

drkl

astro1
Regular Member

Joined: 26/06/2016
Location: Australia
Posts: 52

Posted: 12:38am 03 Aug 2017

Copy link to clipboard

Print this post

Hi Geoff,
New code writing and reading well.
Thanks,
astro1

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3282

Posted: 03:10am 03 Aug 2017

Copy link to clipboard

Print this post

Thanks, I will declare this working (famous last words) and add it to the Micromite distribution.

Thanks to everyone who found that it did and, just as importantly, did not work. It was a great example of many people working to deliver to a good outcome. Three cheers for the beta testers!

Geoff

Geoff Graham - http://geoffg.net

SteveA
Regular Member

Joined: 10/03/2017
Location: United Kingdom
Posts: 48

Posted: 04:00am 03 Aug 2017

Copy link to clipboard

Print this post

Works well on a MM+

I found that at 3V3, a 100K pull up resistor on the data pin and a 100nf decoupling capacitor eliminated the occasional failed read.

Just one thing! The pdf says it will work on *any* pin, however, it wouldn't work on pin 50 which is SCLK. I assume this was down to hardware differences between this and normal I/O pins?

Grogster

Admin Group

Joined: 31/12/2012
Location: New Zealand
Posts: 9586

Posted: 01:04am 04 Aug 2017

Copy link to clipboard

Print this post

Based on that, I would strongly recommend that the 100k pullup and 100n cap be standard practise with these chips. IMHO, I would be inclined to make the resistor 10k rather then 100k, just to give the I/O pin a reasonably firm pull-up rather then a weak one, which often also helps to prevent jitter confusing the connected device. Only my 2c though. Make of that what you will.

Smoke makes things work. When the smoke gets out, it stops!

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3282

Posted: 05:33am 04 Aug 2017

Copy link to clipboard

Print this post

SteveA said The pdf says it will work on *any* pin, however, it wouldn't work on pin 50 which is SCLK. I assume this was down to hardware differences between this and normal I/O pins?

There is nothing different between that and any other pin (I am assuming here that you are talking about the 64 pin MM+). Are you using SPI1 at the same time, it uses pin 50 for the SPI clock?

Geoff

Geoff Graham - http://geoffg.net

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3282

Posted: 05:48am 04 Aug 2017

Copy link to clipboard

Print this post

Grogster said I would be inclined to make the resistor 10k rather then 100k, just to give the I/O pin a reasonably firm pull-up rather then a weak one

The UNI/O chip seems to have trouble pulling the pin low if the pullup is too strong.

This is what TassyJim found:

TassyJim said I put the cro on and did some experimenting with different values of pull-up resistor. With no resistor, one direction goes from ~zero to a high of ~2.5V. With a 10k pull-up it goes from ~0.5V to 3.3V. That seems to agree with the data sheet. I tried a 100k resistor and got close to full voltage swing so will stay with that.

Geoff

Geoff Graham - http://geoffg.net

Nathan
Regular Member

Joined: 10/01/2016
Location: Germany
Posts: 49

Posted: 10:59am 04 Aug 2017

Copy link to clipboard

Print this post

Hi,

some small estimations

(not an exact calculation, only to get a feeling)

lets use Ilowmax something between 200 and 300uA, lets take 240um
Rmin = (VDD - Vlowmax) / Ilowmax
Rmin = ( 3.3V - 0.4V) / 240uA = 12KOhm

IhighMax = leakageIo + leakageUnio = lets say a max around 4-8uA
Rmax = (VDD - 0.7*VDD) / Ihighmax = 0.3 *VDD / Ihighmax = 0.3 *3.3 / 8uA = 123KOhm
Rmax = (VDD - 0.7*VDD) / Ihighmax = 0.3 *VDD / Ihighmax = 0.3 *3.3 / 4uA = 246KOhm

So a 10k Resistor is below or at the border (no low margin anymore)
Rmax strongly depends on the estimated/expected leakage, which limits the high
level during floating bus stage.

If the leakage is to high the signal will no reach a secure high stage in time.
So what to use?

In case the device does not work on some pins I would give a ~56k Ohm resistor a chance. The 100k should be fine in low leakage situations. A non 5V tolerant pin
is a good choice, too.

Max bus cap should not excceed 100pF (pin cap of all devices on the bus and wire cap)
A 100nF cap near the supply pins is required, too. No long wires.

I would use the same supply than than the CPU to keep the h/l switch levels in an acceptable range, that's the reason, why I used 3.3V for estimation.

for real values a pcb-board simulation would be required,
including the pin caps.

Nathan

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3282

Posted: 11:46am 04 Aug 2017

Copy link to clipboard

Print this post

I should also mention that the UNI/O driver enables a weak pullup on the I/O pin.

Geoff

Geoff Graham - http://geoffg.net

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6268

Posted: 11:53am 04 Aug 2017

Copy link to clipboard

Print this post

I didn't try any pullup values other than 10k and 100k.
The only capacitor I used was a 0.01uF across the power supply pins. Nothing on the data line.
Once I saw close to full supply rail swings on the data line, I stopped playing.

In my setup I have the UNI/O on a flying lead about 75mm long.
There would have been some loading from the CRO/logic analyzer probes.

Jim

VK7JH
MMedit

Page 2 of 3

Print this page