REALTEK_RTL8195AM: FlashIAP read and address scope

[marcuschangarm]

Description

The FlashIAP is supposed to have access to the full application
memory, so the address scope has been changed to encompass
the entire external flash.

The address translation has also been changed to reflect the memory
layout in the documentation:

Realtek Ameba1 Memory Layout: 5.1 Flash Memory

Related PRs

Needs API change from #4720 to work.

Tests

Tested using GCC and ARM.

+---------------------------+-------------------+-----------------------------+---------------------------+--------+--------+--------+--------------------+
| target                    | platform_name     | test suite                  | test case                 | passed | failed | result | elapsed_time (sec) |
+---------------------------+-------------------+-----------------------------+---------------------------+--------+--------+--------+--------------------+
| REALTEK_RTL8195AM-ARM     | REALTEK_RTL8195AM | tests-mbed_drivers-flashiap | FlashIAP - init           | 1      | 0      | OK     | 0.01               |
| REALTEK_RTL8195AM-ARM     | REALTEK_RTL8195AM | tests-mbed_drivers-flashiap | FlashIAP - program        | 1      | 0      | OK     | 0.17               |
| REALTEK_RTL8195AM-ARM     | REALTEK_RTL8195AM | tests-mbed_drivers-flashiap | FlashIAP - program errors | 1      | 0      | OK     | 0.02               |
| REALTEK_RTL8195AM-GCC_ARM | REALTEK_RTL8195AM | tests-mbed_drivers-flashiap | FlashIAP - init           | 1      | 0      | OK     | 0.01               |
| REALTEK_RTL8195AM-GCC_ARM | REALTEK_RTL8195AM | tests-mbed_drivers-flashiap | FlashIAP - program        | 1      | 0      | OK     | 0.17               |
| REALTEK_RTL8195AM-GCC_ARM | REALTEK_RTL8195AM | tests-mbed_drivers-flashiap | FlashIAP - program errors | 1      | 0      | OK     | 0.02               |
+---------------------------+-------------------+-----------------------------+---------------------------+--------+--------+--------+--------------------+

[theotherjimmy]

@adbridge Could you review this?

[theotherjimmy]

@c1728p9 Could you review?

[theotherjimmy]

/morph test

[0xc0170]

@Archcady

[Archcady]

So the flash address starts from 0x0? The Image 1 (0x0000 - 0xAFFF) area is not for application usage, so maybe the flash accessible address should start from 0xB000 (which is start address of Image 2)

[marcuschangarm]

As far as I understand, the purpose of the API is to give unrestricted access to the NVM where the application is stored and users of this API knows that all safeties are off.

[Archcady]

If that's the case, I'll agree to start from 0x0000.

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 835

Test failed!

[studavekar]

/morph test

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 841

Test failed!

[0xc0170]

There was a problem with bot, let me restart the job

/morph test

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 850

All builds and test passed!

[marcuschangarm]

I fixed a bug preventing the mbed-hal flash test to pass.

In some instances the flash_on command wasn't called.

[0xc0170]

/morph test

[0xc0170]

@Archcady please rereview

[Archcady]

Looks good, thanks.

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 858

All builds and test passed!