AM2431: Trying to update project to SDK 9.02.01 but getting assert

Hello,

Jeff Hendrix said:

Bootslot start addr: 0x100000
TR Response failed for transfer : SRC = 0x60120000, DST = 0x70070000, SIZE = 64512
ASSERT: 0.702190s: ospi/v0/dma/udma/ospi_dma_udma.c:OspiDma_udmaUpdateSubmitTR:242: FALSE failed !!!

Could you please share the full boot logs?

How do I capture the boot logs?

This is serial output on a production board.

Hello,

If you are doing migration, I assume you are in development stage so you have full access to the board and any logs. I would like to have a look on the full boot logs from your bootloader.

Additionally, I would also like you to enable the Sysfw traces and share those logs.

The Sysfw logs can be enabled as follows:

• Change "#undef SYSFW_TRACE_ENABLE" to "#define SYSFW_TRACE_ENABLE" in source/drivers/sciclient/sciclient_default_boardcfg/am64x/sciclient_defaultBoardcfg.c.
• Build the board configurations with: make -s -C tools/sysfw/boardcfg
• Add another UART instance in the SBL for MAIN_UART1.
• Build the SBL.

Regards,

Prashant

I'm on a windows machine, and when I try to build the board config file, I get this

PS C:\ti\mcu_plus_sdk_am243x_09_02_00_50> make -s -C tools/sysfw/boardcfg
makefile:5: /imports.mak: No such file or directory
makefile:6: /devconfig/devconfig.mak: No such file or directory
C:\gnu_unix\usr\local\wbin\make.exe: *** No rule to make target `/devconfig/devconfig.mak'.  Stop.

Jeff Hendrix said:

C:\gnu_unix\usr\local\wbin\make.exe: *** No rule to make target `/devconfig/devconfig.mak'.  Stop.

Looks like you may be using an old version of make. I have seen this in the past.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1264237/am62a7-why-does-it-can-not-identify-this-command-abspath-of-make-in-windows

You may use the gmake utility shipped with the CCS installation or use at least make v4.x

Regards,

Prashant

Sorry for the slow response. I was chasing down some other issues.

I'm now using a new version of gmake (4.1), but I'm still unable to build the board config
I'm now seeing this error

One of the boardcfg files provided do not exist, exiting blob creation ...
makefile:131: recipe for target 'sciclient_boardcfg' failed
gmake: *** [sciclient_boardcfg] Error 2

This is the line in the makefile that it doesn't like

    $(PYTHON) $(BLOB_GEN) --sw-rev 1 --devgrp $(DEVGRP_MAIN) --bcfg $(BCFG) --bcfg-rm $(BCFG_RM) --bcfg-pm $(BCFG_PM) --bcfg-sec $(BCFG_SEC) --output-file $(BCFG_BLOB_FILE)

And I have not been able to file it's complaining about.

================

On a different note, I have been able to add debug statements in the SDK and rebuild the sbl target
Our failure is happening when the bootloader is trying to hash the firmware stored on the ospi.
We are doing 64k reads into a buffer by calling the function Flash_read().

In the file ospi_dma_udma.c, the function OspiDma_udmaCopy is called which splits the 64k read into 2 calls of sizes 64512 and 1024 and those call the function OspiDma_udmaUpdateSubmitTR().
That function calls Udma_ringDequeueRaw() until a UDMA_SOK is returned and then it checks UdmaUtils_getTrpdTr15Response() and is looking for a return of CSL_UDMAP_TR_RESPONSE_STATUS_COMPLETE.

While doing the hash check, the first 64k chunk is read successfully, but while reading the 2nd 64k chuck, Udma_ringDequeueRaw() returns a UDMA_SOK, but when UdmaUtils_getTrpdTr15Response() is called, a CSL_UDMAP_TR_RESPONSE_STATUS_TRANSFER_ERR is returned.

I've compared those SDK source files in 9.00 to 9.02.01 and they are the same, so there must be something in the included binaries that has changed that's causing the read to fail.

Jeff

Jeff Hendrix said:

I'm now using a new version of gmake (4.1), but I'm still unable to build the board config
I'm now seeing this error

Could you please share the full build logs?

Retrieving the SYSFW logs is important here because there might be a firewall exception for some reason that might be preventing access to the SRAM address 0x70070000.

On another note, the first two SRAM banks (0x70000000-0x70080000) are supposed to be reserved for the SBL as shown

Then, why the SBL is loading application to address 0x70070000?

This is the full log

c:\ti\mcu_plus_sdk_am243x_09_02_01_05>gmake -s -C tools/sysfw/boardcfg
One of the boardcfg files provided do not exist, exiting blob creation ...
makefile:131: recipe for target 'sciclient_boardcfg' failed
gmake: *** [sciclient_boardcfg] Error 2

c:\ti\mcu_plus_sdk_am243x_09_02_01_05>

We have a 64k global buffer that we use for reading in chunks of the flash data for calculating the hash. The 1st 64k chunk is read successfully, it's the 2nd time we try to read that it fails

#define BOOTFLASH_BLOCK_SIZE (64U * 1024U)
unsigned char bootloader_buffer[BOOTFLASH_BLOCK_SIZE];

The same code works perfectly with SDK 9.00

I added SOC=am243x and gmake ran. I rebuilt the project and I didn't get any additional output on the UART.

I also tried adding DEVICE_TYPE=HS (since we are using a HS_SF chip) and it also didn't add any additional output.

We already had a UART defined in the project, so I renamed it MAIN_UART1
This is what it's now set to (my DebugP_log() messages are coming out, but that's all)

Jeff Hendrix said:

I also tried adding DEVICE_TYPE=HS (since we are using a HS_SF chip) and it also didn't add any additional output.

Please keep DEVICE_TYPE=GP only. HS is for HSSE only.

Jeff Hendrix said:

We already had a UART defined in the project, so I renamed it MAIN_UART1

You just changed the identifier which is just used as in index in the source code. What I meant was you have to add an additional UART with "+ADD" and then make sure this has UART Instance set to USART1 like so

The DebugP_log prints will come on UART0 as usual while SYSFW logs, if enabled, will come on UART1. These will be different ports on the PC.

I added another UART like you showed above.
The current port I'm monitoring doesn't show any additional output. I'm not sure what other port to use on the PC. The board I'm testing on is a production board and I have a FTDI cable hooked up to it's serial port. I see that the XDS adds 2 serial ports, but I'm not seeing any data on either of those.
I've also notice now that the board is resetting after it prints out part of the error message and keeps repeating

Bootloader v3
Bootslot start addr: 0x100000
TR Response failed for transfer : SRC = 0x6012ð

Hello,

It depends on your board schematics if the UART1 is even enabled. You may have to hook some jumpers or something to expose the UART1 port.

In any case, let's just forget UART. Could you please take the SYSFW logs from memory buffer using the debugger?

On another note, if you do not use DMA to transfer data, does any issue occur or the board boots all the way as expected?

Regards,

Prashant

Our UART1 is connected to another processor on the board, so that's probably not going to work.

I did capture the memory buffer. I have it saved in multiple formats (the Ti Raw and COFF look very similar).
(how do I attach the logs?)

I turned off DMA and our code gets past the hash check. It fails for another check, but it's not in the SDK. It does take a lot longer to get through this step without DMA (we had to turn it on to meet timing requirements for other parts of our system).

Here is the TI Raw Data trace

0x60C000B9
0x60C000B2
0xC20102
0xC20024
0x61800102
0x61C00092
0x62000001
0xC2010D
0xC20024
0x6180010D
0x61C00092
0x61276CB2
0xC2010C
0xC20024
0x6180010C
0x61C00092
0x61276CB2
0x61276CB2
0xC20101
0xC20024
0x61800101
0x61C0007F
0xC20104
0xC20024
0x61800104
0x61C0007F
0xC20103
0xC20024
0x61800103
0x61C0007F
0xC20100
0xC20024
0x61800100
0x61C0007F
0x62000000
0x60C0007A
0xC20102
0xC20024
0x61800102
0x61C0007F
0x62000001
0xC2010D
0xC20024
0x6180010D
0x61C0007F
0x7111FC01
0xC20102
0xC20024
0x61800102
0x61C0007F
0x62000002
0x6140047A
0xC2010D
0xC20024
0x6180010D
0x61C0007F
0x6117FC3F
0xC2010C
0xC20024
0x6180010C
0x61C0007F
0x6117FC3F
0x6117FC3F
0xC21500
0xC20024
0x4F4E00FF
0x4F4A001A
0x4F4B0020
0x4F4606A0
0x4F4C000C
0x4F4D0006
0x4F4F0000
0x4F500000
0xC21500
0xC20024
0x4F4E00FF
0x4F4A001A
0x4F4B0022
0x4F4606A2
0x4F4C0006
0x4F4D0006
0x4F4F0000
0x4F500000
0xC21500
0xC20024
0x4F4E00FF
0x4F4A001A
0x4F4B0021
0x4F4606A1
0x4F4C0006
0x4F4D0006
0x4F4F0000
0x4F500000
0xC21500
0xC20024
0x4F4E00FF
0x4F4A001C
0x4F4B000D
0x4F46070D
0x4F4C0210
0x4F4D0100
0x4F4F0000
0x4F500000
0xC21500
0xC20024
0x4F4E00FF
0x4F4A001C
0x4F4B000A
0x4F46070A
0x4F4C002C
0x4F4D000E
0x4F4F0000
0x4F500000
0xC21110
0xC20024
0x41070000
0x410800BF
0x4F8A00FF
0x4F8B0001
0x4F80001A
0x4100001A
0x4F01000C
0x4F06068D
0x4F0A0024
0x4101000C
0x410C0001
0x410D7008
0x410E1D00
0x410F0000
0x41100001
0x41110000
0x4F8A00FF
0x4F8B0001
0x4F80001A
0x4100001A
0x4F8A00FF
0x4F8B0001
0x4F80001A
0x4100001A
0x41070000
0x410800BF
0x4F8A00FF
0x4F8B0001
0x4F80001A
0x4100001A
Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x42FD4
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x42FD4
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x42F7C
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x42F7C
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x42F7C
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x42F7C
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x44000
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x44000
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x44000
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x44000
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x44000
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x4427C
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x44C04
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x4539C
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x45D24
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x464A8
 0x0
 0x421BD4
 0x4

Exception addr  0x45B00000
FWL Exception  0x1020100
 0x30000
 0x46E34
 0x0
 0x421BD4
 0x4

4001
0x63D02002
0x64504001
0x63100016
0x64502002
0x63D06002
0x64506002
0x63D08002
0x64508002
0x63C00050
0x64400050
0x63C02001
0x64402001
0x6300005C
0x63C04003
0x64404003
0x63C06004
0x64406004
0x63C10004
0x64410004
0x63C1C002
0x6441C002
0x63C30004
0x64430004
0x63C32003
0x64432003
0x68400000
0x60C000A3
0xC20102
0xC20024
0x61800102
0x61C0184B
0x62000007
0xC2010D
0xC20024
0x6180010D
0x61C0184B
0x612B7C88
0xC2010C
0xC20024
0x6180010C
0x61C0184B
0x612B7C88
0x612B7C88
0xC20101
0xC20024
0x61800101
0x61C00098
0xC20104
0xC20024
0x61800104
0x61C00098
0xC20103
0xC20024
0x61800103
0x61C00098
0xC20100
0xC20024
0x61800100
0x61C00098
0x62000000
0x60C000BA
0x60C000B3
0xC20102
0xC20024
0x61800102
0x61C00098
0x62000001
0xC2010D
0xC20024
0x6180010D
0x61C00098
0x61276CB3
0xC2010C
0xC20024
0x6180010C
0x61C00098
0x61276CB3
0x61276CB3
0xC20101
0xC20024
0x61800101
0x61C00092
0xC20104
0xC20024
0x61800104
0x61C00092
0xC20103
0xC20024
0x61800103
0x61C00092
0xC20100
0xC20024
0x61800100
0x61C00092
0x62000000

Thanks for sharing the logs!!

There are some firewall exceptions but they don't seem to be related to the issue. I am also not confident if these are correct logs because the transactions for which firewall exceptions are generated are tagged with debug flag meaning debug transactions. Are you running the SBL under the control of the debugger?

Since you have everything working with v9.0, I would also like you to try the following steps once:

• Build the v9.2 SBL with no "-s" flag in the make command to generate the full build logs.
• In these logs, you will find a rom_image_gen.py command that generates the ROM bootable SBL image (tiimage).
  

  ❯ make -C examples/drivers/boot/sbl_ospi/am243x-evm/r5fss0-0_nortos/ti-arm-clang scrub all | grep rom_image_gen
  python3 /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/tools/boot/signing/rom_image_gen.py --swrv 1 --sbl-bin /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/examples/drivers/boot/sbl_ospi/am243x-evm/r5fss0-0_nortos/ti-arm-clang/sbl_ospi.release.bin --sysfw-bin /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/source/drivers/sciclient/soc/am64x_am243x/sysfw-hs-fs-enc.bin --sysfw-inner-cert /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/source/drivers/sciclient/soc/am64x_am243x/sysfw-hs-fs-enc-cert.bin --boardcfg-blob /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/source/drivers/sciclient/sciclient_default_boardcfg/am243x/boardcfg_blob.bin --sbl-loadaddr 0x70000000 --sysfw-loadaddr 0x44000 --bcfg-loadaddr 0x7B000 --key /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/tools/boot/signing/rom_degenerateKey.pem --rom-image /home/p-shivhare/ti/mcu_plus_sdk/am243x/common/examples/drivers/boot/sbl_ospi/am243x-evm/r5fss0-0_nortos/ti-arm-clang/sbl_ospi.release.hs_fs.tiimage

• Take this command as it is and replace just the SBL binary path (--sbl-bin) to point to your Raw v9.0 SBL binary.
• Run the command to generate the ROM bootable SBL image (tiimage).

If the bootable SBL (tiimage) generated after the above commands results in the expected boot then this means something is wrong with the v9.2 SBL binary only otherwise something is with the other components (mostly Board Configurations).

I built the bootloader with SDK 9.00 and ran the make from above. I then replaced the --sbl-bin path with --sbl-bin path from my build and ran the python script. I flashed the created tiimage onto the am243 and it successfully went through the boot loader.

Hello,

Jeff Hendrix said:

I flashed the created tiimage onto the am243 and it successfully went through the boot loader.

Just to confirm, this SBL tiimage, which is booting successfully, is built with the SBL binary from SDK v9.0 and the other components from SDK v9.2? If the SBL tiimage is built with all components from SDK v9.2, the boot again fails?

In the later case, could you please share the image?

Regards,

Prashant

Yes. I even reinstalled the 9.02.01 SDK first (so it had none of my changes in it). I did the ti-arm-clang scrub all and took the command it showed and replaced --sbl-bin path with the bootloader.bin file that was generated from a 9.00 build and ran the python command. I put the generated file on our board and it made it through the hash check portion of our bootloader.

Hello,

I did some testing today mostly same as your setup meaning 64K DMA reads using Flash_read multiple times and was able to do it successfully with SDK v9.2. So, this is mostly something specific to your bootloader.

There is no reason for the DMA to fail considering the first 64K chunk read is successful.

Let me loop in the DMA expert for some inputs here!!

Regards,

Prashant

Hello,

Just in case, I have used the following test function in the SBL_OSPI

#define BOOTFLASH_BLOCK_SIZE (64U * 1024U)
unsigned char bootloader_buffer[BOOTFLASH_BLOCK_SIZE] __attribute__((section(".bss.buf")));

void test_func()
{
    DebugP_log("/* Being testing */\r\n");

    Flash_Handle handle = Flash_getHandle(0);

    uint32_t base_offset = 0x100000;

    for(uint32_t i = 0; i < 25; i++) {
        Flash_read(handle, base_offset + i * BOOTFLASH_BLOCK_SIZE, bootloader_buffer, BOOTFLASH_BLOCK_SIZE);
    }
    
    DebugP_log("/* End testing */\r\n");
}

and these are the successful logs

DMSC Firmware Version 9.2.8--v09.02.08 (Kool Koala)
DMSC Firmware revision 0x9
DMSC ABI revision 3.1

/* Being testing */
TR Response success for transfer : SRC = 0x60100000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6010FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60110000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6011FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60120000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6012FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60130000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6013FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60140000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6014FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60150000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6015FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60160000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6016FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60170000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6017FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60180000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6018FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60190000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6019FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x601A0000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x601AFC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x601B0000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x601BFC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x601C0000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x601CFC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x601D0000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x601DFC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x601E0000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x601EFC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x601F0000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x601FFC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60200000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6020FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60210000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6021FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60220000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6022FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60230000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6023FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60240000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6024FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60250000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6025FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60260000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6026FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60270000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6027FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60280000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6028FC00, DST = 0x7007FC00, SIZE = 1024
/* End testing */
[BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH
KPI_DATA: [BOOTLOADER_PROFILE] Boot Media Clock : 166.667 MHz
KPI_DATA: [BOOTLOADER_PROFILE] Boot Image Size  : 0 KB
[BOOTLOADER_PROFILE] Cores present    :
r5f0-0
KPI_DATA: [BOOTLOADER PROFILE] SYSFW init                       :      12373us
KPI_DATA: [BOOTLOADER PROFILE] System_init                      :     365267us
KPI_DATA: [BOOTLOADER PROFILE] Drivers_open                     :        316us
KPI_DATA: [BOOTLOADER PROFILE] Board_driversOpen                :      32361us
KPI_DATA: [BOOTLOADER PROFILE] Sciclient Get Version            :       9990us
KPI_DATA: [BOOTLOADER PROFILE] CPU load                         :     419895us
KPI_DATA: [BOOTLOADER_PROFILE] SBL Total Time Taken             :     840209us

Image loading done, switching to application ...
TR Response success for transfer : SRC = 0x60080700, DST = 0x7008000D, SIZE = 129024
TR Response success for transfer : SRC = 0x6009FF00, DST = 0x7009F80D, SIZE = 17536
TR Response success for transfer : SRC = 0x600A43A0, DST = 0x700B1241, SIZE = 4992
Hello World!

The "TR Response success" logs are generated because of the following patch

diff --git a/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c b/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
index b34df4d2..27c3a184 100644
--- a/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
+++ b/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
@@ -245,6 +245,7 @@ static int32_t OspiDma_udmaUpdateSubmitTR(void* ospiDmaArgs, void* dst, void* sr
         }
     }
 
+    DebugP_log("TR Response success for transfer : SRC = 0x%X, DST = 0x%X, SIZE = %u\r\n", (uint32_t)src, (uint32_t)dst, length);
     return status;
 }
 
@@ -295,4 +296,4 @@ static int32_t OspiDma_udmaCopy(void* ospiDmaArgs, void* dst, void* src, uint32_
     }
 
     return status;
-}
\ No newline at end of file
+}

Is it possible if you could share such test function with which you are able to see the issue. I will give that a try and see if it is reproducible.

Otherwise, could you apply the following patch to reliably dump the SYSFW logs at the exact point of failure

diff --git a/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c b/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
index b34df4d2..c0d0394c 100644
--- a/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
+++ b/source/drivers/ospi/v0/dma/udma/ospi_dma_udma.c
@@ -182,6 +182,24 @@ static int32_t OspiDma_udmaClose(OSPI_DmaHandle handle, void* ospiDmaArgs)
 
 }
 
+void dump_sysfw_logs()
+{
+    #define SYSFW_LOGS_BUFFER_ADDR 0x44043000
+    #define SYSFW_LOGS_BUFFER_SIZE 0x0FE0
+
+    uint8_t* ptr = (uint8_t*)SYSFW_LOGS_BUFFER_ADDR;
+
+    DebugP_log("\r\n<<SYSFW_LOGS\r\n");
+
+    for(int32_t i = 0; i < SYSFW_LOGS_BUFFER_SIZE; i++)
+    {
+        DebugP_log("%c", *ptr);
+        ptr++;
+    }
+
+    DebugP_log("\r\nSYSFW_LOGS\r\n");
+}
+
 static int32_t OspiDma_udmaUpdateSubmitTR(void* ospiDmaArgs, void* dst, void* src, uint16_t icnt[4])
 {
     int32_t status = UDMA_SOK;
@@ -239,12 +257,14 @@ static int32_t OspiDma_udmaUpdateSubmitTR(void* ospiDmaArgs, void* dst, void* sr
             if(trRespStatus != CSL_UDMAP_TR_RESPONSE_STATUS_COMPLETE)
             {
                 DebugP_log("TR Response failed for transfer : SRC = 0x%X, DST = 0x%X, SIZE = %u\r\n", (uint32_t)src, (uint32_t)dst, length);
+                dump_sysfw_logs();
                 DebugP_assert(FALSE);
             }
             break;
         }
     }
 
+    DebugP_log("TR Response success for transfer : SRC = 0x%X, DST = 0x%X, SIZE = %u\r\n", (uint32_t)src, (uint32_t)dst, length);
     return status;
 }
 
@@ -295,4 +315,4 @@ static int32_t OspiDma_udmaCopy(void* ospiDmaArgs, void* dst, void* src, uint32_
     }
 
     return status;
-}
\ No newline at end of file
+}

With this patch, the SYSFW logs will be read from the memory buffer and dumped on the same UART as used by your bootloader.

Regards,

Prashant

Hello Jeff,

Can you please try with size value 64*1024–1 and see if this works or not?

The maximum value for 64KB is 65535.

Even if you are passing more than 64 Kbytes, the OSPI DMA driver into two transfers, one for 64512 and another for 1024 bytes in this case, you also don't get an issue. Please look at the Prashant logs. The same should also work for you.

Regards,

Anil.

Thanks for the info, I will try some tests.

One thing that we are doing that's different is we are reading into the same destination memory (we are hashing 64k at a time, then reusing the memory).

Could you modify your test to do that and see if it makes a difference while I run some more tests? (I'm also working some other issues, so it might take me a while to do this)

Thanks

Jeff Hendrix said:

One thing that we are doing that's different is we are reading into the same destination memory (we are hashing 64k at a time, then reusing the memory).

I actually tested like this only. I have kept the test setup similar to yours. This means, I am doing 64K DMA reads using Flash_read into the same 64K destination buffer located at the same location (0x70070000) as yours. You may see the logs as well.

Oh sorry, you are right. I had quickly glanced at the DST addresses and saw the first 2 were different and didn't realize it was doing the 64512 / 1024 split reads.

I added your test_func() and called it before our hash check and I got the following

/* Being testing */
TR Response failed for transfer : SRC = 0x60110000, DST = 0x70070000, SIZE = 64512
ASSERT: 0.689303s: ospi/v0/dma/udma/ospi_dma_udma.c:OspiDma_udmaUpdateSubmitTR:242: FALSE failed !!!

I then added the other debug info and moved the call to test_func() a little bit earlier and I'm now getting the following and it keeps repeating

/* Being testing */
TR Response success for transfer : SRC = 0x60100000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6010FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60110000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6011FC00, DST = 0x7007FC00, SIZE = 1024
/* Being testing */
TR Response success for transfer : SRC = 0x60100000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6010FC00, DST = 0x7007FC00, SIZE = 1024
TR Response success for transfer : SRC = 0x60110000, DST = 0x70070000, SIZE = 64512
TR Response success for transfer : SRC = 0x6011FC00, DST = 0x7007FC00, SIZE = 1024

I compared our main code with the code in examples\drivers\boot\sbl_ospi\am243x-evm\r5fss0-0_nortos\main.c and they almost match.

Where in your main function did you put the call to test_func()

Is it possible there is something in example.syscfg that is causing the problem?

Hello Jeff,

Can you please share the images for both test cases ?

Actually, udma_drivers open API will be called the Drivers_open function.

Once, channel is initialized then  we should to use the DMA .

So, your test function also should be called after the Drivers_open API.

Regards,

Anil.

I put the call to test_func() right after these 2 lines

Drivers_open();
Bootloader_profileAddProfilePoint("Drivers_open");

and now the only output I see is

/* Being testing */

What does your example.syscfg file look like?

Hello Jeff,

We used the same system cfg  file , which is available from the SBL_OSPI  application.

Regards,

Anil.

Our solution for now is to build the bootloader with SDK 9.00 and our main FW with SDK 9.02.01 (so far tests have been working)

Hello Jeff,

So, now SBL 09.00 with the 09.02 MCU+SDK Application is working.

And, SBL 09.02 with the  09.02 MCU+SDK Application is not working and your SBL is throwing an error at DMA copy operation.

This is my understanding. Please correct me if I am wrong.

Regards,

Anil.

Looks like the bootloader portion is working OK, but when we get to the main firmware, it will eventually hang. Looks like it has something to do with the I2C. Doing more investigating.

Hello Jeff ,

Please let me know exactly where your code is hanging ?

Is it during I2C clock  initializations in your Main Firmware Application and which I2C is like I2 0 or I2C 1?

If you share details, I can give some suggestions.

Regards,

Anil.