Elektroda.com
Elektroda.com
X

BK7231 programming via SPI in flash memory mode - Python and Banana Pi

p.kaczmarek2 4506 23
This content has been translated flag-pl » flag-en View the original version here.
  • BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    BK7231 is usually programmed via UART - this is allowed by the bootloader uploaded by the manufacturer. In exceptional situations, however, we can accidentally overwrite this bootloader - then we have to use the SPI programming mode to recover the blocked system. Here I will describe how the SPI mode works in BK7231 and I will present the simple code of my own primitive SPI programmer for Beken. The "programmer" will be written in Python and will run on a Raspberry Pi (okay, here on Banana Pi - but it's very similar on Raspberry).

    SPI interface in BK7231
    Consider the derivation of BK7231:
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    We see the pins: P20, P21, P22, P23 (SCK, CSN, SI and SO). Contrary to appearances, it is not an external memory interface, as in ESP8266, here Beken itself is memory.
    Beken is an SPI memory and identifies itself as 00 15 70 1C, so it looks like a bone similar to EN25QH16B - and the EN25QH16B datasheet with read / write operations can brighten the situation a bit here.
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    Below is a preview of three commands from EN25QH16B that we will use.
    Page read (command 0x03):
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    Deleting a sector - sector erase (command 0x20):
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    Programming (saving data) to the page - page program (command 0x02):
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    Additionally, access to the status register may be useful (to check if, for example, the operation was performed):
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    It is worth emphasizing that subscribing to a page requires first deleting it. Page erase sets its bits to 1, and writing can 'blank' selected bits. Writing cannot 'light up' these bits - that's what erase is for. Interestingly, it allows for various combinations with saving flash page deletion cycles, but more on that another time.
    It is similar at BK - let's see how.
    But first you have to run the SPI mode at all ...

    How to put BK7231 into SPI mode?
    The algorithm is simple. The algorithm below will execute my script.
    - we initiate SPI in mode 3 (0b11 mode), frequency 30kHz (faster ones did not work for me)
    - we set the CEN to a low state
    - we wait 1 second
    - we set the CEN to a high state
    - we send D2 250 times after SPI
    - we expect an answer once D2, then 249 times 00
    From then on, Beken is in SPI mode. This can be checked by sending a request for ID - 9F 00 00 00. Expected answer:
    00 15 70 1C.
    Then you can operate on the Flash memory - read it or write to it (writing must be preceded by its deletion). Both reading and writing are per-page, i.e. 256 bytes each.
    The format of the read and write commands is simple - first one command byte (as I mentioned - 0x02 page write, 0x03 read, etc.) and then 3 bytes of the address.
    What is the easiest way to do it? Probably on the Raspberry PI. I used Banana Pi myself because I had one at hand.

    Patient from the subject
    Here is the aforementioned module with a damaged bootloader - BK7231T on a board with readily available signals from SPI.
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    As a supplement, I will add that in the picture above we have pins:
    - TX and RX (normal UART programming)
    - TX2 and RX2 (log UART)
    - IO0 - it's probably a remnant of ESP, I don't know what it's for
    - RST - I didn't check what it was for, but it's probably RESET
    - CE (CEN) - this is the pin I reset BK7231
    - SO, SI, SCK, CSN - SPI interface
    - ground and 3.3V power supply - you know

    Preparation of Banana Pi
    The version used is exactly the Banana Pi BPI-M1 +, although I hope it doesn't matter here. It should be quite similar on the popular Raspberry.
    I started completely at 0. I downloaded Armbian. The version used is:
    Armbian_22.08.7_Bananapi_bullseye_current_5.15.74.img
    https://www.armbian.com/banana-pi-plus/
    I uploaded it to the SD card via Etcher.
    From the hardware side, I took the SPI pins from here:
    https://wiki.banana-pi.org/Banana_Pi_BPI-M1%2B#Hardware_interface
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    BK7231T already connected:
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    For SPI control I used spidev (available on both Banana Pi and Raspberry Pi):
    https://pypi.org/project/spidev/
    For ease of use, I used a virtual Python environment. Commands as on the screen, sequentially:
    - python3 -m venv env - the command creates a virtual environment
    - source env / bin / activate - the command activates them (after restarting the system, they should also be activated again, at least I had to every time ...)
    - python -m pip install spidev - command installs packages; in the screenshot there is also tqdm and pyserial, but they were not needed in the end
    Here is the spidev installation (and more):
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    You also had to turn on SPI. At first I thought that it would be enough to change "armbian-config" (this command invokes such a tool):
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    But no. You had to add one more line to /boot/armbianEnv.txt in the file editor :
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    I wrote param_spidev_spi_bus = 0 to /boot/armbianEnv.txt.


    The GPIO library was also missing. I had to use RPi.GPIO_BP as RPi.GPIO replacement for BananaPi, hence:
    https://github.com/LeMaker/RPi.GPIO_BP
    I made a copy of the repository and wanted to install as instructed in the repo, but it was not without problems.
    I've had a lot of problems multiple definition of linker errors.
    The solution was to add -fcommon down CFLAGS .
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi


    Writing a Python Program
    Now it's time for proper programming. I wrote the program on a Windows computer via FTP client - Filezille and Notepad ++ text editor. I have already done all tests and commissioning on Banana Pi.

    Running SPI and GPIO in Python
    My SPI flasher program starts with SPI and CEN pin configuration:
    Code: python
    Log in, to see the code

    I used RAW addressing mode for GPIO, because on Banana Pi I couldn't find information about other ways of pin addressing. I run SPI in mode 3, with a frequency of 30,000, because in the case of higher frequencies I was not able to read the memory ID.
    Now it's time to start the SPI mode in BK ...

    Establishing communication in the SPI mode
    First, we set the low state to CEN per second:
    Code: python
    Log in, to see the code

    And then we send the byte 0xD2 250 times:
    Code: python
    Log in, to see the code

    It is also worth somehow verifying whether the SPI mode has been set for sure, and whether our chosen communication speed is not too high. The easiest way to do it is by querying for the Flash memory ID, i.e. the command 0x9F 0x00 0x00 0x00:
    Code: python
    Log in, to see the code

    The above code checks what we have received - we expect ID 0x00 0x1c 0x70 0x15 and we return 1 or 0 depending on it.
    This will allow us to detect possible communication problems early.
    The code could be improved - in case of failure, for example, try again with a slower transfer speed.
    The photo shows the first success of establishing SPI communication:
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi

    Reading SPI memory
    Details of data reading can be found either in the SPI memory documentation and in the Tuya SDK.
    Code: python
    Log in, to see the code

    Reading the memory boils down to sending 0x03 commands with an appropriately encoded address. The address is encoded as 3 bytes, and the first byte is the command code - 0x03. 0x03 this is a full page read.
    On the occasion of reading, I write the data to the file - the variable 'f'.


    Writing to SPI memory
    We used to read memory page by page, now it's time for page write.
    Unfortunately, here you will also need to delete the sector first - that is, we need two commands:
    Code: python
    Log in, to see the code

    Auxiliary functions, to wait for the completion of the operation and to perform the enable (in the while loop; I have not described this step in detail, but here it is also analogous to the SPI):
    Code: python
    Log in, to see the code

    Here is the full feature:
    Code: python
    Log in, to see the code

    As before - one command byte, three address bytes. First, we delete the contents of the memory, then write to it.


    BK7231 programming via SPI
    We have almost everything - just use it.
    Thanks to this, we will recover BK7231 with overwritten UART bootloader.
    Basically, we now have two options.
    1. full OpenBeken upload - we need a QIO version with a bootloader. The UA version is not suitable as it does not contain a bootloader and starts with an offset of 0x11000.
    Code: python
    Log in, to see the code

    2. we can also restore the original batch ripped by e.g. bkWriter 1.60, which by default reads from the offset 0x11000. For this purpose, we take the bootloader from QIO, and then load the original batch:
    Code: python
    Log in, to see the code

    If our REST.bin file contains the original Tuya software, this procedure will restore it on our BK7231.

    Ready program on Github
    You can download the full program from my repository. You can also improve it and open new ones pull request :
    https://github.com/openshwprojects/BK7231_SPI_Flasher

    Summary
    With this simple program you can bring the BK7231 back to life, although it should be remembered that without the removed SPI pins it can be difficult.
    With my program, I was able to bring back to life two BK7231.
    Someone might still be wondering why I didn't try to use incomplete Tuya code from hid_download_py? It just did not work for me - in theory it supports several versions of Beken chips, but in my opinion it is too complicated and problematic. He was spilling out somewhere before SPI, on some weirder reset procedure.
    I am enclosing a catalog note of the Flash memory on which:. in I was based - it can explain a bit more than the topic, it's worth having a look, each command is described in more detail there, as is the status register.

    Cool? Ranking DIY
    Do you have a problem with Raspberry? Ask question. Visit our forum Raspberry.
    About Author
    p.kaczmarek2
    Moderator Smart Home
    Offline 
    p.kaczmarek2 wrote 5827 posts with rating 5811, helped 278 times. Been with us since 2014 year.
  • #2
    danaia
    Level 2  
    I've been trying this method to resurrect a BK7231T with no success as of yet. I'm using a Raspberry Pi Zero, SPI seems to be functional (tested with spi_test).
    I soldered wires to SPI_* pins on the chip (on the right of the diagram). However, I noticed that this guide specifies that the FLASH_* pins are to be used (which are on the top of the diagram). Could you specify which pins are supposed to be used? Thanks
  • #3
    p.kaczmarek2
    Moderator Smart Home
    Hello @danaia, it seems that you are correct. It must be an editing error. All my boards used for experiments have already broken out pins so I didn't verify that. You should try these pins:
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    Please report here if it works for you or not.
  • #4
    danaia
    Level 2  
    It worked! I have the WBLC5 board, so I was able to used its provided pads instead of soldering directly to the chip.
    The device ID wasn't correct with 30000Hz configured, so I tried some random values and ended up succeeding with 3000Hz.
    Thanks for the guide!
  • #5
    p.kaczmarek2
    Moderator Smart Home
    3000Hz is very slow. I wonder if it would have worked for you in 20 000Hz mode or something like that, but anyway, the most important thing is that it worked out! Good job, I'm glad I helped.
    Is there anything else I may help you with?
  • #6
    danaia
    Level 2  
    Hahah yeah, it certainly wasn't fast, but I didn't want to stop it once it got going :D
    Not right now, thanks :) Got the LEDs mostly working so I'll post again if something comes up further down the line.
  • #7
    blowagie
    Level 5  
    Thanks a lot for this manual. I've used this procedure to recover from a wrong flash I did before. My CB2S module has a BK7231T chip installed instead of a BK7231N.

    BK7231 programming via SPI in flash memory mode - Python and Banana Pi

    To flash an image with the bootloader, I used my OrangePi PC with some modifications of the code:
    import OPi.GPIO as GPIO
    CENGPIO = 3
    GPIO.setboard(GPIO.PCPCPLUS)
    GPIO.setmode(GPIO.BOARD)

    I also had some compilations problems which where fixed by:
    export CFLAGS=-fcommon

    pip install --upgrade pip
    pip install wheel
    pip install spidev
    pip install OrangePi.GPIO

    I also needed to adjust the sleep from 1 second to 0.2 seconds before the the chip went into SPI mode.

    I wired the PINS as follow:
    Black CEN --> PIN 3
    Brown SCK --> PIN 19
    Orange SO --> PIN 21
    White SCK --> PIN 23
    RED CSN --> PIN24
    Purple VBAT --> PIN 1
    Blue GND --> PIN 39

    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi

    Bart
  • #8
    p.kaczmarek2
    Moderator Smart Home
    CB2S with BK7231T... I have never expected to see such an oddity. I wonder what was the story behind it. A BK7231N shortage? A production error?

    Anyway, good job. That bit of information with 0.2 also might be useful.
  • #9
    fagnerlins08
    Level 2  
    >>20268279


    Hello goodnight

    Could you adapt the script to use with the arduino mega 2560? would be very grateful to you
  • #10
    p.kaczmarek2
    Moderator Smart Home
    It should be possible, but Arduino Mega 2560 doesn't have enough memory space to keep whole BK7231 dump, so we would have to also write some kind of mechanism to send the BK7231 binary file from PC to Atmega part by part first. I mean, send a chunk, flash it, send a chunk, flash it, etc.
  • #11
    fagnerlins08
    Level 2  
    Could you provide a script for this? I have my device dead and I have no other way to recover it, I would be very grateful.
  • #12
    p.kaczmarek2
    Moderator Smart Home
    I would have to write such a script from scratch and I would also need to test it on my side. I may look into it into the following weeks, I don't have a setup for that right now.
    I think that script would need to utilize Serial port in Arduino to send flash chunks (sectors?) from PC to the Arduino, and then Arduino would send them via SPI to BK.
    That script would also require some kind of little utility on the PC side so it sends the BK flash data sector by sector via UART.
    What kind of dead module do you have? WB3S?

    How well do you know Arduino programming? Maybe we could try to write such script together. Our ElektrodaBot could also help.
  • #13
    fagnerlins08
    Level 2  
    It's an addressable led strip with BK7231T microphone chip, I don't even have a knowledge about arduino I started with it today :(

    I even ran the firmware on the device, but I couldn't control it, not even a command that was sent worked.

    BK7231 programming via SPI in flash memory mode - Python and Banana Pi BK7231 programming via SPI in flash memory mode - Python and Banana Pi BK7231 programming via SPI in flash memory mode - Python and Banana Pi
  • #14
    slaweb91
    Level 4  
    I do SPI on WB2S

    root@raspberrypi:~# python beken_sp_flash.py
    /root/beken_sp_flash.py:13: RuntimeWarning: This channel is already in use, continuing anyway. Use GPIO.setwarnings(False) to disable warnings.
    GPIO.setup(CENGPIO, GPIO.OUT)
    Send 250 'D2'
    0x0 0x52 0xd2 0xd2 0xd2 0xd2 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 Test by sending get ID
    0x0 0x1c 0x70 0x15 ID OK
    WriteImage OpenBK7231T_QIO_1.17.105.bin
    count 0/2097152
    count 256/2097152
    -
    -
    count 2096384/2097152
    count 2096640/2097152
    count 2096896/2097152
    root@raspberrypi:~#


    This code (https://github.com/openshwprojects/BK7231_SPI_Flasher/blob/main/bk7231_spi_flasher.py) but only
    custom this:

    CENGPIO = 3
    GPIO.setmode(GPIO.BOARD)
    spi.max_speed_hz = 2500
    WriteImage(0,"OpenBK7231T_QIO_1.17.105.bin", 0x200000)

    After finishing nothing is happening Chip don't send me wi-fi OpenBKxxx or anything...I found dump that i get from that device before i kill him with this command:

    WriteImage(0,"OpenBK7231T_QIO_1.17.105.bin", 0x11000)
    WriteImage(0x11000,"dump.bin", 0x200000)

    All goes ok but in the end nothing...

    Any ideas?

    Thanks
  • #16
    slaweb91
    Level 4  
    Ok, how can do that? I never to SPI before now :)

    Added after 11 [minutes]:

    When I connect the chip to USB-TTL and try to connect with bk7231flasher I can't get anything...I start all and 1sec I connect CEN to GND but nothing.

    It seems to get stuck somewhere when starting.

    Can I get some log from SPI because SPI works fine...

    Test by sending get ID
    0x0 0x1c 0x70 0x15 ID OK
  • #17
    p.kaczmarek2
    Moderator Smart Home
    No, you don't get debug log from SPI. Debug log can be accessed via UART, you need USB to UART dongle, solder the RX of your dongle to TX2 pin of Beken and use RealTerm or any other terminal app to receive the data at 115200 baud. This will tell you whether OBK at least boots up, or is the module still totally dead.
  • #18
    slaweb91
    Level 4  
    Unfortunately nothing...only blue LED work. As soon as I turn it on, the LED lights up and when I connect CEN to GND in ms off and again LED is on. LED doesn't blink...works constantly.

    BK7231 programming via SPI in flash memory mode - Python and Banana Pi BK7231 programming via SPI in flash memory mode - Python and Banana Pi


    I wouldn't bother you anymore...obviously, the chip has died...I just don't know how SPI works, I can probably access the flash memory somehow. The only thing is that I might try an older version of OpenBK( I use the newest) https://github.com/openshwprojects/OpenBK7231T_App/releases/download/1.17.109/OpenBK7231T_QIO_1.17.109.bin.

    Everything goes OK with SPI, without any errors but for some reason, it won't boot.
  • #19
    p.kaczmarek2
    Moderator Smart Home
    It's not "bothering", I am happy to help. Please ask much as you want. We're here to help you.

    Ok, so now, are you really, 100% sure that you are getting nothing from TX2 pin?

    Please keep UART terminal open and then power off and on the BK7231.

    Keep only power connected, because it may be in RESET state due to the CEN connection at low level, that's why it prints nothing.

    Check again if it prints anything. It should at least print the chip name at 115200 baud.

    If device is alive, even with broken bootloader, you should get:
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
  • #20
    slaweb91
    Level 4  
    Ok, so now, are you really, 100% sure that you are getting nothing from TX2 pin?

    ----Nothing, when I power off and on BK in ms, I get RX on COOLTERM software goes green but nothing to see on console.


    ----You meen 1TX because i dont have that TX2 pin on wb2s chip?

    Is there any other way to make the chip alive again...some other script, firmware, etc

    Thanks for help
  • #21
    p.kaczmarek2
    Moderator Smart Home
    slaweb91 wrote:

    ----You meen 1TX because i dont have that TX2 pin on wb2s chip?

    No, I mean TX2, the UART1 is for programming via bootloader, and UART2 is for debug log.
    Hmm it seems to be marked 2TX on silkscreen, but still, 2TX (UART 2 TX) is a debug log output.
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    Let me be clear:
    BK7231 programming via SPI in flash memory mode - Python and Banana Pi
    You will get log output at TX2 (2TX, UART2TX, etc, etc, etc).
  • #22
    slaweb91
    Level 4  
    I just did that but unfortunately, I get absolutely nothing.

    I connect my 3.3 gnd and rx(from uart) to 2tx(wb2s) and I start CoolTerm...10 times I turn off and on 3.3 for wb2s but nothing.

    I can only connect to SPI and do flash but in the end nothing...

    I order 1pcs of ESP-02S and I will flesh that chip with tasmota and replace him with my wb2s :(

    I dont have any more ideas how can I back to life my wb2s.


    First I dump flash with "bk7231tools read_flash -d /dev/ttyUSB0 -s 0 -l 0x200000 dump.bin"

    And that was ok i get dump.bin orginal firmware.

    After that i copy command that i use for cb2s(day before I flesh that chip without any problem, but his offset is 0x0 and i didnt see that)

    bk7231tools write_flash -d /dev/ttyUSB0 -s 0x0 -l 0x200000 --bootloader OpenBK7231T_UA_1.17.105.bin

    And after that I get dead chip :)

    This i think was i right command:

    bk7231tools write_flash -d /dev/ttyUSB0 -s 0x11000 -S 0x11000 -l 0x20000 OpenBK7231T_UA_1.17.105.bin

    But in future I will use flasher with GUI...
  • #23
    p.kaczmarek2
    Moderator Smart Home
    @slaweb91 , can you check one more thing?

    First do SPI script to write bootloader only:
    
    WriteImage(0,"OpenBK7231T_App_QIO_35a81303.bin", 0x11000)
    

    and then modify SPI script to do only a data read, first 0x11000 bytes, and compare if the data that you have read is the same as the data that you've written?
  • #24
    slaweb91
    Level 4  
    I think I broke him 100%

    I write:

    WriteImage(0,"dump.bin", 0x200000)

    dump.bin is firmware is original firmware that I dump before I broke him.

    After this write, I can get into SPI mode again.

    I get:
    Test by sending get ID
    0x0 0x0 0x0 0x0 ID bad

    TX2 doesn't work again, only the blue LED works :)

    I order a replacement chip for 2 USD...that is not a problem, but I had a desire to fix this one and learn something new along the way!

    One question, I have a door lock with a WBRU Tuya chip (https://computervillagemart.com.ng/image/cache/catalog/smart%20lock/TUYA%20WIFI%20Face%20Recognition%20Smart%20Door%20Lock_2-500x515.jpg)
    is there any custom solutions for this lock to work with Home Assistant (MQTT). I could not find anything for this chip on the internet...

    Thanks.

    Added after 11 [hours] 11 [minutes]:

    >>20578026

    SPI_READ_REG = 0x05

    def Wait_Busy_Down():
    while True:
    send_buf = bytearray(2)
    send_buf[0] = SPI_READ_REG
    send_buf[1] = 0x00
    out_buf = spi.xfer2(send_buf)
    if not (out_buf[1] & 0x01):
    break
    time.sleep(0.01)

    def CHIP_ENABLE_Command():
    send_buf = bytearray(1)
    send_buf[0] = SPI_CHIP_ENABLE_CMD
    spi.xfer(send_buf)
    Wait_Busy_Down()


    What do I need to edit if I somehow enter to SPI mode again when i try next time...