Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dolu1990
    @Dolu1990
    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
    Dolu1990
    @Dolu1990
    there is dedicated commands
    one CS with 0x66 , then another CS with 0x99
    the keywords in the datasheet is "software reset"
    emard
    @emard
    Is software reset issued before or after 0xAB
    Dolu1990
    @Dolu1990
    That, i don't know
    THe data sheet isn't clear
    i put it after the wake up
    as it seem to me that it would work in both cases
    emard
    @emard
    What is done by saxonsoc, is that software reset is done AFTER 0xAB command??
    Dolu1990
    @Dolu1990
    yes
    in the last fix i pushed, yes
    emard
    @emard
    OK! I will test it independently what happens
    emard
    @emard
    @Dolu1990 After software reset, do you wait enough time to for flash to reset? I cant test this because micropython is slow.
    Dolu1990
    @Dolu1990
    200 us
    emard
    @emard
    should be okk
    Dolu1990
    @Dolu1990
    datashet say 30 us, but margin never hurt
    emard
    @emard
    I tried almost all combination software reset before 0xAB, after, both, none and reading with 0xB command all works in every combination on ISSI chip from micropython
    Are those all flash commands used: 0x66, 0x99, 0xAB, 0x0B
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab There is still a problem with lcc C library - the exit function crashes, but_exit is OK. I just built it on SaxonSoc and when I run it, it hits that problem.
    Dolu1990
    @Dolu1990
    yes
    e2kgh
    @e2kgh
    Ok, after recompile I got those bytes from flash: