@Dolu1990 : Sorry, new to this whole thing, and looked in the wrong file. And, it came in, after I updated my git, so didn't see it yet :(
Dolu1990
@Dolu1990
no worries ^^
emard
@emard
@Dolu1990@lawrie Can a print be done for 4 th byte (the byte after reading 3 dummy bytes received after 0xAB command), Flash should respond by 0x17 its described on page 58 of flash datasheet http://www.issi.com/WW/pdf/IS25LP128.pdf
Lawrie Griffiths
@lawrie
@pnru_gitlab In order to do your lcc-compiled as test, I will need to build an lcc-compiled version of as, and for that I will need your two library routines, so can you give me the source of them.
All flashes I know mounted on ulx3s return 0x17 at this place, so it is indication that 0xAB command itself worked and that SPI interface works also.
Dolu1990
@Dolu1990
hmm on my board i got a 0x15
ahhh because that's a winbond
Ok
I will also add a soft reset command
to be sure all the registers are set to default
emard
@emard
I must check on winbond is it really 0x15 returned there
Dolu1990
@Dolu1990
it does
i checked
in datasheet
emard
@emard
I have some early winbond with the same labeling on the chip which returns 0x17 if I issue 0xAB from ecp5.py
But yours may be different inside although outside labelled the same
Dolu1990
@Dolu1990
I pushed the update on SaxonSoc git
emard
@emard
Great! In next compiled binary release I will look what is printed at boot
Dolu1990
@Dolu1990
it also removed the 4 extra bytes on the wake command
emard
@emard
What is wake command hex? I thought 0xAB is used as wake
I want to reproduce on ecp5.py the same flash commnd if I can find that it makes chip go nuts
_
Dolu1990
@Dolu1990
it is
but with single byte
with the 4 extended bytes it become another command
emard
@emard
it is <which hex>?
Dolu1990
@Dolu1990
? 0xAB => wake up 0xAB 0xZZ 0xZZ 0xZZ 0xDeviceId => read device id
Maybe the behaviour of the read device ID is different between the two vendor, on one it also wake up, on the other it don't ?
I don't know
But for sanity i fix it to better match the datasheet XD
Maybe the software reset of the flash will fix the current issue, maybe that corrected wake up will, maybe the issue will remain ^^
emard
@emard
Aha but that is 0xAB issued twice. At least from ISSI datasheet 0xAB is dual function command, regardless how many bytes are shifted later it will wake up chip and return ID. on winbond (mine) it returns 0xFF 0xFF 0xFF 0x17 0x17 ...
dual function is that it 1:wakes up and 2:returns id
The same sequence is on ISSI (first 3 0xFF, rest 0x17 repeating)
emard
@emard
What is hex of software reset command, let me try that also
e2kgh
@e2kgh
@Dolu1990 : saxon_update, doesn't update the saxonsoc.git here. On purpose?
Dolu1990
@Dolu1990
Hooo f* me XD
sorry
not on purpose
Fixed now
If you pull SaxonSoc and resource it, then saxon_update will be fixed
@e2kgh
emard
@emard
@Dolu1990 do you know what is hex sequence of software reset command? I have tested 0xAB with 0-16 number of bytes shifted later and after that always read worked