LP-AM243: OSPI Bootloader Example Issue

Hi,

Thanks for your patience.

Allow me sometime to read through the detailed question and get back to you once I have further updates.

Regards,

Vaibhav

Hi,

Can you try to put the destination buffer in MSRAM?

Please read more here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/MEMORY_MAP.html

Regards,

Vaibhav

I am using the SBL_OSPI example from SDK 10.0.0.

I notice from SDK version 10.0.0-> 10.0.1 this buffer (and supporting code) is added to main.c in the SBL_OSPI example.

So I assume this is the buffer you'd like me to setup?

My system image is 815Kib, so the buffer would need to be placed in an area of MSRAM where the code will be loaded. Will that be a problem?

Can you share the source for the sbl_ospi.debug.hs_fs.tiimage prebuilt bootloader? I would like to know how it is different and why it works, when the example needs modification?

Hi,

Toby Grabham said:

Can you share the source for the sbl_ospi.debug.hs_fs.tiimage prebuilt bootloader?

Source is inside MCU_PLUS_SDK_INSTALL_PATH/examples/drivers/boot/sbl_ospi.

Please read more about it here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/10_01_00_32/exports/docs/api_guide_am243x/EXAMPLES_DRIVERS_SBL_OSPI.html

Toby Grabham said:

So I assume this is the buffer you'd like me to setup?

That is correct. I checked the .app section in the file named sbl_ospi.release.map.

It is allocated under MSRAM, so you have to make sure your destination buffer is in MSRAM in this case.

Regards,

Vaibhav

Moreover, please note the following:

In the latest SDK that is 10.01.00.32

in the file: ospi_lld.h

If you see how OSPI_NOR_PROTOCOL is defined:

#define OSPI_NOR_PROTOCOL(cmd, data, addr, dtr) (uint32_t)(((uint32_t)(dtr) << 24) | \

                                                        ((uint32_t)(cmd) << 16) | \

                                                        ((uint32_t)(addr) << 8) | \

                                                        ((uint32_t)(data) << 0))

It is wrongly mentioned, so it should be written as:

#define OSPI_NOR_PROTOCOL(cmd, addr, data, dtr) (uint32_t)(((uint32_t)(dtr) << 24) | \

                                                        ((uint32_t)(cmd) << 16) | \

                                                        ((uint32_t)(addr) << 8) | \

                                                        ((uint32_t)(data) << 0))

Notice, how I swapped the addr and data, because when you say a protocol like xS-yS-zS then x lines are used for command, y lines are used for address and z lines are used for data.

So please do the changes as I have shown.

And then simply build the driver libraries again by going to command prompt:

I'm a little confused, if the source for the sbl_ospi.debug.hs_fs.tiimage prebuilt image is exactly the same as examples/drivers/boot/sbl_ospi.. then why when I build the completely unmodified example, do I have this problem? Can you explain?

I can try your suggestions in the next couple of days.

Hi Toby,

Toby Grabham said:

I'm a little confused, if the source for the sbl_ospi.debug.hs_fs.tiimage prebuilt image is exactly the same as examples/drivers/boot/sbl_ospi.. then why when I build the completely unmodified example, do I have this problem? Can you explain?

Is your question more of the booting works when using SBL_OSPI default SDK prebuilt images and fails to work when you use the newly built image without modifying the application at all.

If yes, please tell me the steps how you are trying to run the application SBL_OSPI?

Regards,

Vaibhav

OK, bear in mind I'm testing this with SDK 10.0.0.

So, prebuilt SBL image works fine.

I import the sbl_ospi example into CCS and build it without any changes to the code.

I set the AM243x-LP to UART boot and use the CLI version of uniflash with below config file.

I set the AM243x-LP to OSPI boot. It fails to boot.

uniflash config:

The call stack in the screenshots on my first post are from the example, with the only change being that I put the call to loop_forever() at the start so I could connect the debugger while the bootloader was running.

Hi Toby,

Thanks for your patience.

Toby Grabham said:

CLI version of uniflash with below config file

Do you mean to say using the uart_uniflash.py script which incorporates Python commands?

Toby Grabham said:

The call stack in the screenshots on my first post are from the example, with the only change being that I put the call to loop_forever() at the start so I could connect the debugger while the bootloader was running.

Inside SBL_OSPI I have seen where you are seeing data abort error.

Let me follow the same steps as you are doing and see if I can come to a same point as yours.

Regards,

Vaibhav

Vaibhav Kumar said:

Do you mean to say using the uart_uniflash.py script which incorporates Python commands?

Correct, command below.

python c:/ti/mcu_plus_sdk_am243x_10_00_00_20/tools/boot/uart_uniflash.py -p COM13 --cfg=sbl_ospi_debug.cfg

Vaibhav Kumar said:

Let me follow the same steps as you are doing and see if I can come to a same point as yours.

This is a good plan.

Other information that may be relevant: the application I am flashing is generated by a system project and contains images for both cores of the first R5.

The application .hs_fs image file is 816KB.

Vaibhav Kumar said:

Can you explain?

You're looking at SDK version 10.0.1 and I'm using SDK version 10.0.0.

I am looking at 10.0 itself:

I see both 10.0 and 10.01 has the same definition:

I'm going to reinstall mcu_plus_sdk_10.0.0 and check again.

I've re-installed the SDK and that function call is not present.

I can only assume that we modified bootloader_flash.c at some point during development / testing.

I will rebuild the bootloader and test again and let you know if it works. This will be in the next couple of days.

Thank you for your patience.

Toby Grabham said:

I've re-installed the SDK and that function call is not present.

I can only assume that we modified bootloader_flash.c at some point during development / testing.

I will rebuild the bootloader and test again and let you know if it works. This will be in the next couple of days.

Thank you for your patience.

Thanks for reinstalling.

It must be that one of the developers must have modified the API to debug some functionality.

Either way it should work with both the SDKs.

Let me know how it goes.

Looking forward to your response.

Thanks,

Vaibhav

Thanks for your help. Issue resolved.