Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[exatech]

Hi,
I am testing a newly developed board with BT815 and external flash (W25Q128JVSIQ). It is a bare metal board without any link to the "EVE asset builder" utilities.

The display is functioning OK, and I can write text and images from RAM_G. Next step is to show ASTC images from flash, but I cannot get the flash into fast mode. After initialization, REG_FLASH_STATUS = 2 (FLASH_STATUS_BASIC) and CMD_FLASHFAST returns error 0xE002 (no header detected).
I then tried to write the unified.blob file from the "EVE asset builder" directory into the flash using CMD_FLASHUPDATE, dest = 0x800000, src = 0, num=4096 and this returns OK, and I can even read the blob data back from flash, but still CMD_FLASHFAST returns 0xE002.

Does anyone know how to do this? Is there any detailed information about this unified.blob and how to install it? I cannot find it anywhere.
Help is much appreciated,
Thanks, Henk

[BRT Community]

Hello,

1.     You can Program the blob into flash using our EVE Asset Builder utility (please see the attached image).
        https://brtchip.com/eve-toolchains/#EVEAssetBuilder

2.   After the blob is programed,  run the program as below to check the state of Flash:

Code: [Select]

uint32_t Gpu_CoCmd_FlashHelper_SwitchFullMode(Gpu_Hal_Context_t *phost)
{
       uint8_t val;
       /* Try detaching and attaching the flash followed by fast mdoe */
       Gpu_CoCmd_FlashDetach(phost);
       App_Flush_Co_Buffer(phost);
       Gpu_Hal_WaitCmdfifo_empty(phost);
       val = Gpu_Hal_Rd8(phost, REG_FLASH_STATUS);

       if (FLASH_STATUS_DETACHED != val)
       {
              printf("Error, Flash is not able to detatch %d\n", val);
              return 0;
       }

       Gpu_CoCmd_FlashAttach(phost);
       App_Flush_Co_Buffer(phost);
       Gpu_Hal_WaitCmdfifo_empty(phost);
       val = Gpu_Hal_Rd8(phost, REG_FLASH_STATUS);

       if (FLASH_STATUS_BASIC != val)
       {
              printf("Error, Flash is not able to attach %d\n", val);
              return 0;
       }

       Gpu_CoCmd_FlashFast(phost, 0);
       App_Flush_Co_Buffer(phost);
       Gpu_Hal_WaitCmdfifo_empty(phost);
       val = Gpu_Hal_Rd8(phost, REG_FLASH_STATUS);

       if (FLASH_STATUS_FULL != val)
       {
              printf("Error, Flash is not able to get into full mode %d\n", val);
              return 0;
       }
       return 1;
}

Best Regards,
BRT Community

[exatech]

Thanks,
but as I mentioned: the asset builder cannot connect to my board. So, I need my host processor to install the blob. How can I do that?
best regards,
Henk

[Rudolph]

According to page 17 of the Programming Guide cmd_flashfast is not needed to write to the FLASH.
A couple of commands like cmd_flasherase and cmd_flashwrite work in "Basic" state as well and this way the Asset Builder is able to write to the FLASH thru the BT81x even if the FLASH has been erased or is completely new.
My best guess is that "Basic" is using simple SPI and "Full" is using QSPI.

Well, at least in theory it is that way and I experienced cmd_flashwrite not working myself recently.
My code was doing something wrong and I still need to find out what.

[exatech]

Hi Rudolph,
I have no problem writing to the flash. First I copied the data to RAM-G and then issued CMD_FLASHUPDATE with parameters FLASH, RAM_G and 4096. After this, I verified by cycling the power supply, and then reading back 4096 bytes to RAM-G. This verified OK.

The part is indeed new, and the error 0xE002 means: "no header detected in sector 0 – is flash blank?". Yes it is blank, so what to do next? The manuals do not tell me how to "unblank" it.

My board has a CAN interface only (plus an SD-card to transfer the images to the flash once after production), and I cannot see how the Asset Builder would succeed in getting the unified.blob and other files into the device using CAN.

[Rudolph]

I am not sure about cmd_flashupdate since it is not mentioned in the programming manual on page 17.
I went with cmd_flashwrite and for some reason it did not fail but it dod not work exactly either.

However, you could try to add a header to the SPI pins between your controller and the BT815 in order to connect
a VA800A-SPI to it and use the EVE Asset Builder.
This should work when you put your controller into reset.

This is one more reason why I stick with modules like the EVE3-50G, I can detach my controller board and connect
the module to my "EVE2 USB to SPI" from Matrix Orbital or my "Hermes Board" from Riverdi.
The current iteration of my controller board is only 45x36 mm, has a stepdown regulator, a speaker, an ATSAMC21E18A-AU, a LDO for the CAN and a TJA1051 CAN-FD transceiver.
I use a 5cm FFC cable.

[pauljiao]

Thanks,
but as I mentioned: the asset builder cannot connect to my board. So, I need my host processor to install the blob. How can I do that?
best regards,
Henk

Asset Builder requires the FT4222 or MPSSE enabled module to be connected with EVE module.    If you need install the blob,  you may just download the "unified.blob" file which is located at installation path of EAB to RAMG_G,  and call the cmd_flashupdate to program it to flash, assuming the cmd_flashattach has been issued successfully and the flash is in Basic mode.

[darkjezter]

For what it's worth...

I'm in the same situation here, and loosely following the advice here I was able to include the unified blob into my MCU firmware and then write it to the flash through the EVE.

After writing the blob to the first 4K of flash while in basic mode, I was able to successfully switch to full mode.

Not how I'd handle manufacturing, but enough to validate that the prototype is working.  A separate method for loading larger datasets to flash will need to come, and instead of using CANbus (which is also an option at my disposal) I'll probably have to do it through the MCU using the programming header for data transfer.

[exatech]

Hi darkjezter,

So it is possible? I tried, but did not succeed. Can you please share the info? What blob file you use, where you have written it to?
Adding the blob to the MCU firmware is no problem for me: plenty of memory available.

thanks,
Henk

[exatech]

OK, found it: I wrote the blob to FLASH address = 0x800000, and was able to read it back because the flash is 16MB. But the destination should have been relative to the flash address, so 0x00000000:

  tft_start_write(RAM_G);   // dump blob into RAM-G
  sz = sizeof(unifiedblob);
  for (i = 0; i < sz; i++) spi_tx_8(unifiedblob);
  tft_stop();
   
    tft_cmds[0] = CMD_FLASHUPDATE;       // write to flash, erase sector if necessary
    tft_cmds[1] = 0;                                  // destination in flash
    tft_cmds[2] = RAM_G;                          // source in RAM-G
    tft_cmds[3] = sz;                                 // size
    tft_write_fifo((uint8_t*)tft_cmds, 16);


Bridgetek: a bit more documentation could have saved me a lot of time: the unified blob is nowhere to be found in your datasheet of user manual. Please do not mention errors like "Is it blank" without telling how to fix it.
Henk

[BRT Community]

Hello,

Thanks for pointing that out, we will update the documentation.

Best Regards,
BRT Community

[Rudolph]

I am not sure but I might have used 0x800000 as target as well.
But I misplaced that code somehow.
So I tried it again with 0x0000000 as target adress.

And this time it worked on my EVE3-50G on which I replaced the 32MBit flash with a 128MBit type.

I generated a flash.bin with the EVE Asset Builder containing two pictures.
Then I wrote this flash.bin with the EVE Asset Builder to check if my code does display the images correctly and it does.
So I erased the flash with the EVE Asset Builder and linked the flash.bin to my programm.
I added a few lines to execute a cmd_flashwrite() in case the flash status is "2" after trying to put it into FULL mode.
The flash.bin is 22528 bytes long and it gets written now the first time my programm runs after erasing the flash.
After a reset the images are displayed.

The RVT43ULBNWC00 however that I put a SST26VF064BA-101I/SM on is a totally different story.
I can erase the flash just fine with the EVE Asset Builder.
And from my software I can tell it gets detected by the BT815 and put into "BASIC" mode.
But cmd_flashwrite() just silently fails doing nothing.

And when I use the EVE Asset Builder to write the flash.bin I get this:

----
Write D:.../Flash/flash.bin to flash unsuccessfully!
Log:
 Information on channel number 0:
 Flags=0x2
 Type=0x8
 ID=0x4036014
 LocId=0x432
 SerialNumber=
 Description=Single RS232-HS
 ftHandle=0x0

handle=0x76edb8 status=0x0
VC1 register ID after wake up 7c

 reg_touch_rz =0x7fff
 reg_touch_rzthresh =0xffff
 reg_touch_tag_xy=0x80008000
 reg_touch_tag=0x0

Writing Blob file ".\unified.blob" to BT81X Flash Storage
Error, Flash is not able to get into full mode
Fail to write Blob file ".\unified.blob" to BT81X Flash Storage
Existing ...
----

Oh yes, that "Existing" is a typo in the flashtool. :-)

But I wrote it before somewhere else in this forum, the rest of the message is also a bit strange.
Why is the flashtool still insisting on writing "unified.blob" while the blob already is part of the flash.bin?
"Error, Flash is not able to get into full mode" - why is this error even there? Why does it even try to put the flash into full mode?

Bottom line, neither the EVE Asset Builder or my software can write to the Flash of my choice,
is there anything that can be done about this?
Or is there even a reason to this, some incompatibility that maybe is shared with other Flash chips?

[exatech]

Hi Rudolph,
you may want to check CMD_FLASHFAST: in my case it returned error 0xE002 (no header detected).

I do not know what info is in the blob: I read somewhere that it may have to be adopted for different memory sizes, but I cannot find that comment anymore. It would be interesting to know what is exactly in the blob. Have you checked REG_FLASH_SIZE? Does it tell you the correct size of your flash chip?

My approach in these cases is usually to steer clear of wonky tools, and go straight for SPI from my own processor to the chip: that allows deep debugging with the actual chip: make some small tools to read and write to the eeprom through BT815, and get the FlashUpdate command working because it is a lot easier and faster than chip erase: it also leaves your sector 1 intact.
success, Henk. 

[Rudolph]

>you may want to check CMD_FLASHFAST: in my case it returned error 0xE002 (no header detected).

I just tried that and it does return 0xE002.
And it really should return 0xE002 - because the FLASH is empty,
I put a new one on the board and erased it.

>I do not know what info is in the blob

My guess is that this is code for the FT900 like controller in EVE.

>Have you checked REG_FLASH_SIZE? Does it tell you the correct size of your flash chip?

Yes, I have and it reads "8" which is correct for my chip.
And REG_FLASH_STATUS reads "2" which is FLASH_STATUS_BASIC, good to go to be programmed.

And still cmd_flashwrite() fails, nothing gets written and it fails silently without triggering a coprocessor fault.

>and get the FlashUpdate command working because it is a lot easier and faster than chip erase:

Oh, I am pretty sure I got it working, I did not use it so far though.
First the chip already is erased, then it requires to place the data in the ram-g first and to repeat
myself, cmd_flashupdate is not part of the table on page 17.
It should work in BASIC and FULL mode, but the table does not contain this information.
So I am going with cmd_flashwrite for now and it works exactly as it should on my other display.
Okay, okay, I tried using cmd_flashupdate now and it did not work either.

> it also leaves your sector 1 intact.

I really hope it does not because I am trying to write to sector 1 to get the blob installed...

[pauljiao]

Writing Blob file ".\unified.blob" to BT81X Flash Storage
Error, Flash is not able to get into full mode
Fail to write Blob file ".\unified.blob" to BT81X Flash Storage
Existing ...
----

Oh yes, that "Existing" is a typo in the flashtool. :-)

That typo is not seen on my version EAB 1.0.  You might be using old version.