Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Dolu1990
    @Dolu1990
    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:
    SDRAM init
    Mem test .. pass
    Flash ID : 0xFF
    OpenSBI copy
    U-Boot copy
    Image check .. OpenSBI missmatch
    15C83919 F468FE56
    emard
    @emard
    I have tested flash by first entering to deep sleep mode. Flash returns 0xFF constanty when in deep sleep. The correct wake sequence is first to issue 0xAB to wake up. Issuing 0x66 0x99 later doesnt matter but 0x66 0x99 itself will not wake up from deep sleep, behaves consistent an in datasheet
    @e2kgh I get 0xFFFFFFFF to opensbi mismatch
    Something is not identical with our boards. But 0xFF of flash ID means 0xAB command didnt succeed and nothing further can work
    Still it is strange how did you later get non-0xFFFFFF return of reading
    Lawrie Griffiths
    @lawrie
    @pnru_gitlab I added your functions to my fork, and I also needed unlink (as I only had unlinkat) - lawrie/riscv32_lcc@a61b173
    emard
    @emard
    ISSI Flash supports SPI mode 0 and mode 3. maybe this...
    0xAB will be ignored if it is issued when FLASH is already processing something else like erase block or similar
    Paul Ruiz
    @pnru_gitlab
    @emard maybe there is a delay for wakeup from deep sleep to become effective? Just guessing.
    Dolu1990
    @Dolu1990
    would realy need remote access to debug that properly XD
    that's possible
    emard
    @emard
    @pnru_gitlab possible, Im testing it using micropyhton (slow) and I don't need to add any extra delays. Still I think micropython reads it in 50ms after wakeup and all is ok
    Yes remote openocd debug is what we must next do. I cant setup my networking now, only if e2kgh has better situation
    Paul Ruiz
    @pnru_gitlab
    @lawrie: not sure I understand the exit/_exit problem. You mean that it works with an extra _exit(0) at the end of main and does not when you just return from main? Is that for a simple test file or something else?
    Lawrie Griffiths
    @lawrie
    No a call to exit(0) crashes, but _exit(0) does not. Return from main without exit is fine.
    Dolu1990
    @Dolu1990
    remote openocd debug else SSH <3
    Lawrie Griffiths
    @lawrie
    @emard I have updated Smp/bitstreams/ulx3s_85f_green_2core_saxonsoc.bit. On a blue 85f it gives:
    
    SDRAM init
    Mem test .. pass
    Flash ID : 0x17
    OpenSBI copy
    U-Boot copy
    Image check .. pass
    Paul Ruiz
    @pnru_gitlab
    @lawrie - ok that makes sense: as we have it returning from main is almost the same as calling _exit() so that is a relief. The main function of exit() over _exit() is to call the "atexit" functions before doing the real exit. The stdio lib uses this to register a function that flushes all buffers before exit. Probably something goes wrong there.
    emard
    @emard
    @lawrie I will test - as you can see, you have winbond on blue 85F but ID returns 0x17. I found it in images instead of bitstreams :) and does uImage actually need update to see new flash id messages?
    Paul Ruiz
    @pnru_gitlab
    @lawrie I will see if I can replicate the issue on the simulator when I have time - probably not today.
    Lawrie Griffiths
    @lawrie
    @emard Moved to correct place. uImage does not need changing.
    emard
    @emard
    OK
    Lawrie Griffiths
    @lawrie
    These changes are in the bootloader which is in BRAM in the bitstream.
    Lawrie Griffiths
    @lawrie
    It immediately dereferences atexit which will be zero, and crashes.