AM2632: RBL secondary bootlocation 0xF0000 is not working

Hi Jo,

What is the boot mode that you have set? Also is this a HSSE(security enbled) AM263x device? I.e. have you burned your keys already?

Hello Nilabh,

excuse my late answer, but I was not in the office the last weeks.

I think we have a HS-FS device, due to the RBL identification string (received on UART in UART boot mode)

We use the QSPI(4s) boot mode on this customer board.

We have not burned a key to the system.

Best regards,
Jo

We use S25FL128SAGNFI01 in our customer board
The TI eval board uses S25FL128SAGNFI00.

Here a link to the data sheet of the flash devices, which are from the same family... 

www.infineon.com/.../Infineon-S25FL128SS25FL256S_128_Mb_(16_MB)256_Mb_(32_MB)_3.0V_SPI_Flash_Memory-DataSheet-v20_00-EN.pdf

We adapted the erase flash block size in sysconfig from 64kb to 256kb for our sbl_uart_uniflash, which we use for flashing via uniflash-script,

I have done some further tests, and I have recognized, that I only can write my bootloader in the customer board to addresses which are a mutliple of 0x4_0000  (e.g. 0x0_0000, 0x4_0000, 0x8_0000, 0xC_0000, 0x10_0000)

To 0xF_0000  I cannot write in my customer board, I get an error message from uniflash-script.... I think the bootloader is not really written to the alternative boot location...0xF_0000

With the eval-board I can write to all addreses, which are a multiple of 0x1_000 --> 0xF_0000 matches....


I am not an expoert for the flash devices ... do I have to choose a flash device with erase block size of 64kb to solve the problem?


Best regards

Jo

Hi Jo,

This is due to the fact that the flashwriter that Unilfash tool uses is for TI board with the flash part S25FL128SAGNFI00

This I have already done and uniflash works with my customer board in principle...but only with a mutliple of 0x4_0000...and that doesn't match with 0xF_0000...on my customer board am not able to write the bootloader to the flash offset 0xF_0000

With the eval board and the erase block size if 64kb --> writting of the bootlaoder fucntions properly to all adresses, which are a mutliple of 0x1_0000 --> 0xF_0000 matches

May I change my flash device in hardware?

Looks like the issue is specific to flash, can you try running OSPI flash io and see if you are able to do read and writes to the offset without any issue?

This example: https://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/latest/exports/docs/api_guide_am263x/EXAMPLES_DRIVERS_QSPI_FLASH_DIAG.html

and 

software-dl.ti.com/.../EXAMPLES_DRIVERS_QSPI_FLASH_TRANSFER.html

Hello Nilabh,

now I have tried both examples on our customer board.
For the second example (flash-transfer), we had to change the erase block size in the sysconfig-configuration from 64kB to 256kB.

I can write to 0xF0000 in both examples....


With flashing my own SBL with uniflash/uart by python-script we still have the problem, that the flash scipt finishes with an error message...and we are not able to store to address 0xF0000

I have debugged the  project

 https://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/latest/exports/docs/api_guide_am263x/EXAMPLES_DRIVERS_SBL_UART_UNIFLASH.html

which is used for uart_uniflash. Therefore I have recompiled the project with the sysconfig-setting for our flash device (erase block size is 256kB instead the 64kB of the evaluiation board.

I have found the reason for the flashing error. In the file bootloader_uniflash_common.c, there is a check of the flash offset address to be a multiple of the eraseBlockSize...line58ff

I have commented out this check (and recompiled the library), but then I get an verify error if my programmed file is larger than 64kB. The reason for that is, that only the current block is erased during the flash process and the following block not...if I choose 0xF0000 for offset, then only 64kB are usable...the next block is not erased and then the verify crashes....with addresses higher than 0x10_0000 (when file is larger than 64kB)


I think, the check to flash only to offsets, which are a multiple of the erase block size, may have a reason, which I cannot overview....
But with this restriction, it is not possible to use flash devices with a block size other than 64kB in combination with alternative SBL address ot firmware start addresses, which are not a multiple of 0x4_0000)

Now my questions:
What can I do now? Should  we use a flash device with 64kB block size instead?
What is the reason for the code lines (restriction to multiples of eraseBlockSize)

Will be fixed this problem in future?

Best regards
Jo

Jo Scho said:

I think, the check to flash only to offsets, which are a multiple of the erase block size, may have a reason, which I cannot overview....
But with this restriction, it is not possible to use flash devices with a block size other than 64kB in combination with alternative SBL address ot firmware start addresses, which are not a multiple of 0x4_0000)

Hi Jo,

I do not understand this properly, the property of NOR flash is that writes are supported at block level only, so as long as you enter the correct block size thr flash write would work.

Jo Scho said:

What is the reason for the code lines (restriction to multiples of eraseBlockSize)

When it comes to writing for NOR flashes, you will always have to erase the whole block before writing. 

Jo Scho said:

I think, the check to flash only to offsets, which are a multiple of the erase block size, may have a reason, which I cannot overview....
But with this restriction, it is not possible to use flash devices with a block size other than 64kB in combination with alternative SBL address ot firmware start addresses, which are not a multiple of 0x4_0000)

Hi Jo,

I do not understand this properly, the property of NOR flash is that writes are supported at block level only, so as long as you enter the correct block size thr flash write would work.

Jo Scho said:

What is the reason for the code lines (restriction to multiples of eraseBlockSize)

When it comes to writing for NOR flashes, you will always have to erase the whole block before writing. 

You can change the block size in SBL UART UNiflash project syscfg flash parameter,

Have you done that already?