Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab @emard This is my attempt at scripting the whole build of the linux version of riscv32_lcc - https://github.com/lawrie/riscv32_lcc/blob/master/mklinux.sh
    e2kgh
    @e2kgh
    @lawrie : the "saxon_update" is not checked in yet?
    e2kgh
    @e2kgh
    @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.
    Paul Ruiz
    @pnru_gitlab
    Here you go: https://gitlab.com/pnru/ulx3s-misc/-/tree/master/tmp/lcc-riscv/libc
    Upon first read your build script looks ok to me.
    Dolu1990
    @Dolu1990
    @emard I'm adding it
    emard
    @emard
    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
    Dolu1990
    @Dolu1990
    there is dedicated commands
    one CS with 0x66 , then another CS with 0x99
    the keywords in the datasheet is "software reset"