SPI wil niet meewerken

Ik heb er nu een vijfde opgesoldeerd, en die werkt prima?...
Ik denk dat het een timingprobleem is, en de ene net wel en de andere net niet werkt.

Ga eens kijken of de #HOLD pin dat veroorzaakt. (kan theoretisch, want dat zou de beschreven symptomen veroorzaken)
Helaas, zoals @SparkyGSX zegt, er staat weinig over het #HOLD signaal in de DS, zeker niet bij opstarten.
Heb ook een M25P80 geprobeerd, ook dood... (die DS is ook niet erg duidelijk over #HOLD)
Een voorbeeldschakeling in de datasheet zou in dit geval ook wel handig zijn...

Hij spuugt nu tenminste netjes zijn 16 hex serienummer uit...

@oxurane: HW reset staat default uit in de chip, is dan het #HOLD signaal...

Enige waar ik iets over #HOLD kon vinden was in de DS van de AT25 flash, die schijnt een interne pull-up te hebben, dus mag je 'm los laten.

Maar daar staat weer niet HOE je de pin aan Vcc moet knopen...
(de IS25 heeft duidelijk geen interne pull-up; als je de pin aanraakt gaat 'ie alle kanten op...)

Net #HOLD los gemaakt en via 10k pull-up + 100nF, geen problemen meer...
(gelukkig, ik bouw liever geen apparaten die over AI beschikken... )

Ik zou de hold/reset pin optillen van het board, met een draadje naar een microcontroller pin brengen (eventueel met een weerstandje in serie), en die een laag-hoog cyclus geven, even wachten, en dan gaan communiceren. Misschien kun je op die manier het probleem isoleren.

Daarbij: wees blij dat de 5de werkte, en niet de eerste, dan had je dit probleem veel later pas gevonden.

[Bericht gewijzigd door SparkyGSX op 20 juli 2019 17:02:53 (17%)]

Ik bedoelde dat ook de chips die niet werkten nu ook weer werken met de pull-up R + 100nF...
In de uiteindelijke print gebruik ik #HOLD nooit (voor normale toepassingen zie ik weinig nut), dus een RC is wel zo prettig...

Mooi om te zien dat je er eindelijk data uit kunt persen !
Vraag blijft wat de exacte oorzaak zou kunnen zijn. Van de andere kant, je kunt nu voorzichtig verder werken.

Lijkt dus dat de chip in #HOLD schiet bij opstarten, waar je zo niet meer uit kunt komen. (chip maakt MISO tristate, en reageert nergens meer op)
Vertraging met R+C lost dat op...

Maar helaas zijn datasheets tegenwoordig onduidelijk(er) of er staat gewoon onzin in.
Met bijv. de ADP5062 ben ik ook een hele tijd bezig geweest. Er ontbreekt veel, en er staat veel onzin in die totaal niet klopt...
Jammer, want 't is een hele fijne chip (Li-Ion charger)

Bij de Analog support zei men dan meestal 'dat had inderdaad wat duidelijker gekund'...
(toen schreef ik terug 'nee, niet duidelijker, het klopt gewwoon niet wat er staat, da's heel wat anders... )

[Bericht gewijzigd door Arco op 20 juli 2019 18:05:26 (18%)]

In het begin post je een schema met Hold hard aan de V33. Maar je post ook dat je hem mag laten zweven. Dus wat is er nu verandert? Je laat de hold nu eerst even 0V zijn en dan langzaam met de RC combinatie gaat hij naar de 5V?3,3V

Nee, naar 3.3v (5v gebruik ik al jaren niet meer... )
Bij sommige types van die serial flash mag je 'm laten zweven onmdqat er een interne pull-up in zit. Maar dat geldt niet voor de IS25

Ik vind dat de pin met deze formulering gewoon met een draadje aan VCC mag. Niets onduidelijk. Ze zeggen dat ie aan VCC mag, dus dan mag het met een draadje.

Bij deze (AT25) misschien wel, maar om ook andere type serial flash te kunnen gebruiken, moet je dus een R/C voorzien op de print...

Komt je spanning wel netjes op? Want een RC op #HOLD is toch niet volgens de datasheet, en doet mij vermoeden dat de flash niet goed inschakeld.

De datasheet zegt weinig over #HOLD, en zeker niet bij het opstarten. Voeding is een standaard TPS73733, nog nooit problemen mee gehad.
Ik denk dat de hold later opkomt als de Vcc waardoor de chip in hold schiet...

Vreemd genoeg schijnt de SOIC8-wide versie wel te werken. (ik had er per ongeluk een paar besteld, wist niet dat ze in 2 maten bestonden... )
Enige wat ik me kan voorstellen is dat de timing iets anders is door de langere bonding wires in de chip, maar da's wel een heeel miniem verschil in timing (pS)...
(ik neem tenminste aan dat de die in beide chips gelijk is)

Langere poten (het wireframe) zorgen ook voor meer capaciteit. Het verschil hoeft maar een paar ns te zijn.
Had de oude print misschien bovenop een GND plane ipv een 3V3 plane?

Toch vermoed ik een ander probleem.

dwz, het kan best dat het probleem nu weg lijkt te zijn, maar of je het nu opgelost hebt... Ik weet het niet.

Om het te debuggen zou ik overwegen om hold evt tijdelijk aan een pootje van je CPU te hangen. Dan kan je hem togglen zoveel je wilt.

Het lijkt me trouwens ook stug dat ie "in hold schiet" omdat ie op de FLANK 0->1 van HOLD zou reageren, en die nooit gezien heeft als hold aan VCC hangt. Dat is gewoon een level-triggered signaal en hoog-is-chip-actief.

Ander dingetje om te proberen is om toch de 2 niet-juiste SPI modes te proberen. Mogelijk leer je iets van wat er dan gebeurt.....

Ik doe dat nog wel eens als ik tijd over heb (en dat heb ik momenteel niet echt... )

Er is nergens iets gespecificeerd over het #HOLD signaal, ook niet bij het opstarten. #HOLD hangt ook samen met de status van de SCLK pin.
Feit is dat het vertragen van de #HOLD het probleem 100% oplost. Ik kan het probleem eens bij ISSI voorleggen, wat zij daarover kunnen zeggen...

(ik heb ook liever een oplossing die technisch uit te leggen en te verklaren is...)

@fatbeard: Beide printen hebben een gnd plane aan de onderzijde en een 3v3 plane boven.

8.3 HOLD OPERATION
HOLD# is used in conjunction with CE# to select the device. When the device is selected and a serial sequence is
underway, HOLD# can be used to pause the serial communication with the master device without resetting the
serial sequence. To pause, HOLD# is brought low while the SCK signal is low. To resume serial communication,
HOLD# is brought high while the SCK signal is low (SCK may still toggle during HOLD). Inputs to SI will be ignored
while SO is in the high impedance state, during HOLD.

Daar staat niets over de opstart van de chip, alleen van het normaal gebruik van de pin ...
Ik wacht het antwoord van Issi af...

Een simpel applicatieschema en/of timing diagram bij power-on zou een hoop onduidelijkheid uitsparen...

[Bericht gewijzigd door Arco op 21 juli 2019 21:59:21 (29%)]

Low active, dus permanet aan de voeding zou voldoende moeten zijn, je kan toch een 0Ω (pull-up)weerstandje plaatsen?

Dat had ik, dat werkt dus juist niet...

Vreemd,

HOLD# or RESET#/Serial Data IO (IO3): When the QE bit of Status Register is set
to “1”, HOLD# pin or RESET# is not available since it becomes IO3. When QE=0, the
pin acts as HOLD# or RESET# and either one can be selected by the P7 bit setting
in Read Register. HOLD# will be selected if P7=0 (Default) and RESET# will be
selected if P7=1.
The HOLD# pin allows the device to be paused while it is selected. It pauses serial
communication by the master device without resetting the serial sequence. The
HOLD# pin is active low. When HOLD# is in a low state and CE# is low, the SO pin
will be at high impedance. Device operation can resume when HOLD# pin is brought
to a high state.
RESET# pin is a hardware RESET signal. When RESET# is driven HIGH, the
memory is in the normal operating mode. When RESET# is driven LOW, the memory
enters reset mode and output is High-Z. If RESET# is driven LOW while an internal
WRITE, PROGRAM, or ERASE operation is in progress, data may be lost

wat heb je met het QE bit in het status register gedaan ?

[EDIT} maakt eigelijk niet uit, de chip van het werkende bord deed het ook niet, dus het kan ook niet aan de batch liggen.

wat heb je met het QE bit in het status register gedaan ?

Weinig uiteraard, want de chip reageert nergens op

In de datasheet hebben ze het ook over een flank op de hold pin die "tegelijk" komt met een clock flank, zonder te specificeren wat de tolerantie op "tegelijk" dan is. Een femtoseconde?

Slecht verhaal, die datasheet, en wellicht ook de chip zelf. Daarbij zie ik ook niet echt in wat het doel van die functionaliteit moet zijn, duurt het opzetten van een transactie zo lang dat dit loont?

Vreemd dat veel fabrikanten niet begrijpen dat het wel of niet succes hebben van een chip veel afhangt van de duidelijkheid en juistheid van de datasheet...

Kortom: Gewoon een andere chip kiezen die hetzelfde doet? "Dat zal ze leren"

Daarbij zie ik ook niet echt in wat het doel van die functionaliteit moet zijn, duurt het opzetten van een transactie zo lang dat dit loont?

Ik kan me nog iets voorstellen van 2 chippies op SPI waarbij je wat van de ene naar de andere copieert. Nu kun je de boel 'on hold' zetten zonder een hele transactie opnieuw te hoeven starten. Als 'de andere kant' dat ook kan... Maar *ik* heb dat nog nooit nodig gehad...

Er staat nog wel iets in de datasheet over hoe snel je tegen die chip aan mag kletsen na power-up. En dat de CS# voor die tijd hoog moet zijn, ze adviseren een pull-up. Zou daar nog ellende kunnen zitten?
Ik kan me zo voorstellen dat de HOLD# wat dingen blokkeert (gewoon wat gates die dingen 'los' halen van de buitenwereld) en dat wanneer je wat later met HOLD# bent, het per ongeluk goed gaat.

Volgens support mag de state van de #HOLD lijn bij opstarten niets uitmaken...

Hi Peter,

The failure cannot be explained logically. Since the HOLD# is not latching mechanism, it shouldn’t be relevant powers-up in #HOLD state.
In addition, you are powering up with the HOLD# hard-tied to Vcc, so the SPI device cannot go into HOLD# state.

Since the cause of the failure is not clear, I cannot answer it is a good 'fix' or not.
Only I can say is that the connection of a pull-up (10k) between #HOLD and Vcc and a 100nF capacitor between #HOLD is OK for our device.
Even hard-tied to Vcc for HOLD# is OK.

To clarify the failure cause, please check the scope signals when you power up including Vcc, CE# HOLD#, SI, SO. You might find the clue of the failure.

Best regards,

KJ Jang (x5137)