AM2432: AM2432 OSPI Flash Access 0x60000000

Hi,;

I was browsing through the code base, but could not find the macros defined. Hence, I believe these are custom macros which you have introduced in your application.

With the offsets defined in your application, are you going to just perform reads from the flash. If yes, then from which location will you read from the flash.

If you are going to perform write as well, then let me know the offset as well for the same. Make sure to perform erase before you write.

Regards,

Vaibhav

Hi.

Thank you for your reply.

The flash is using W25Q128, defined in sysconfig below.

As mentioned before, flash reads and writes can be accessed using the provided API.

As far as I know, OSIP recognizes the 0x60000000 area as a flash access address.

However, with the same source code,
Industrial 9.0.0.03 version is accessible and supports read and write operations.
As shown in the function below:
web_fp = (char *)(HTTP_FLASH_FILE_BASE_ADDRESS + HTTP_FLASH_FILE_START_ADDRESS);

However, Industrial 11.0.0.08 version does not support read and write operations.

web_fp = (char *)(HTTP_FLASH_FILE_BASE_ADDRESS + HTTP_FLASH_FILE_START_ADDRESS);

I need to directly access Flash's area in the function to support read/write functionality, but when I change the SDK, this part doesn't work.

Please tell me what I need to change and how to proceed.

I'll wait for your reply.

Thank you.

To explain further,

The actual flash offset is 0x00E00400.

I want to check the value of this part,

web_fp = (char *)(HTTP_FLASH_FILE_BASE_ADDRESS + HTTP_FLASH_FILE_START_ADDRESS);

This means I want to access and read it directly, like this:

web_fp = (char *)(HTTP_FLASH_FILE_BASE_ADDRESS + HTTP_FLASH_FILE_START_ADDRESS);

This is direct access, not using the flash API.

The problem is that this part differs in behavior between IND SDK versions 09 and 11.

I'd like to know what I need to change.

Thank you.

Hi,

I have checked the SysConfig screenshots which you attached.

If you can revisit those in your application and compare the MPU ARMv7 configurations. If they are exactly same, then we can move forward.

Now, when you say access fails, what is actually happening.

So earlier, when you tried to access the data from the offset: 0x00E00400, you were able to read it correctly?

If not, what was the behaviour you saw? data abort, incorrect data read, please elaborate a bit more.

Regards,

Vaibhav

Hi,

The MPU ARMv7 settings in sysconfig used in Industrial SDK 9.0.0.03 and in sysconfig used in Industrial SDK 11.0.0.08 are identical.

(Photo of the sysconfig settings attached at first)

Is there another section in sysconfig that configures these settings?

Since the SDK versions are different, the sysconfig versions are also different.

Industrial SDK 9.0.0.03 sysconfig version.

Industrial SDK 11.0.0.08의 sysconfig version.

The functions below work properly in both SDK versions.

Flash_read(ospiHandle, HTTP_FLASH_FILE_START_ADDRESS, (uint8_t *)g_ucWebFlash, sizeof(g_ucWebFlash);

The Flash data value is successfully retrieved.

However, direct access fails in Industrial SDK version 11.0.0.08.

web_fp = (char *)(HTTP_FLASH_FILE_BASE_ADDRESS + HTTP_FLASH_FILE_START_ADDRESS);

Because the string required for implementation exists at that offset, the CPU freezes when using the lwip_strnstr(web_fp, str, MAX_WEB_STRING_LENGTH); function. (It appears to be a symptom of the task freezing or being stuck in a while loop.)

Because the string is mutable, I want to directly access it using a pointer and compare it.

What is the problem?

Why does behavior change depending on the SDK version?

It worked well in Industrial SDK 9.0.0.03, but why doesn't it work well in Industrial SDK 11.0.0.08?

I will wait for your reply.

Thank you.

Hi.

While testing this and that, I successfully used the function below for direct access!

Flash_Handle ospiHandle = Flash_getHandle(FLASH_INSTANCE_ID);

Flash_enableDacMode(ospiHandle);

I have a question.
If I use the above functions in a local function and then directly access them, do I need to call the Flash_enableDacMode function again when I try to access them again from another location?

If I call it locally and then directly access it, will the Register be disabled again?

If I call the Flash_enableDacMode function wherever direct access is called, it works fine. If I don't, access is blocked.

I'll wait for your reply.

Thank you.

Hi,

Thank you for your answer.

I understand to some extent.

However, it took a long time to find the Flash_enableDacMode function.

I have a question while testing.

In your answer, you said that the Flash_enableDacMode function doesn't need to be called again once it's been called.

However, this differs from the behavior I'm testing.

Multiple tasks are running, and there are functions in certain tasks that directly access 0x60000000.

When the first task calls Flash_enableDacMode and reads data, and then another task tries to access 0x60000000,
the access fails unless Flash_enableDacMode is called again before the access.

So, right now, every time 0x60000000 is accessed, the function calls Flash_enableDacMode.

Note that I do not call Flash_disableDacMode anywhere in my project.

What should I check?

Thank you.

Hi,

Allow me sometime to check the updated API Flash_enableDacMode.

I will get back to you as soon as possible.

Thanks,

Vaibhav

If you call the top level enable dac mode function, you will see at the low level it calls the function OSPI_lld_enableDacMode.

This is responsible for setting the DAC bit.

Now, when you say you have others tasks, are these also running on the same core?

If yes, then it must be just that, when you reach the other task where you want to access the flash region (0x60000000 + flash size), then by that time the DAC bit is set back to 0. Please check by the time you reach the another task, is the DAC bit set to 0? FYI, The DAC bit is only set 0 in case of Flash writes.

Thanks,

Vaibhav

Thank you for your reply.

Multiple tasks are running on the same core.

As I understand it,
I need to set the DAC bit (0x60000000 + flash size) whenever multiple tasks directly access flash memory.

So, the correct way to do this is to call Flash_enableDacMode for each direct access, as I'm testing, right?

This is the part that differs from the Industrial SDK version 09.

Thank you.

Hi,

KIM Jinbo said:

So, the correct way to do this is to call Flash_enableDacMode for each direct access

Your understanding is correct.

Thanks,

Vaibhav