W600-PICO region FLASH overflowed

[federico]

W600-PICO - region 'FLASH' overflow - in firmware compiling

I compiled the WinnerMicro micropython port w60 firmware -(*) FATFS=1 with a GCC 4.9 compiler ( ARM Toolchain) as recommended in micropython/ports/w60x/README.md achieving at the end of the compilation the following message:

region 'FLASH' overflowed by 40000 bytes
( see picture nr.1)

The image size exceeding the software defined max Kb size, produces the error message that stop the building process.
The problem is the same also with (*)LITTLEFS=1 that requires a greater image size compared to the FATfs one.
( see picture nr.2)

(*) In the w60x port Makefile we can set the binaries flags for the image filesystem - FATFS or LITTLEFS and for board flash size - 1MB or 2MB - setting them to 0 or 1.
( see pictures nr.3 and nr.4)

The work-around ( and only idea )that I have adopted to jump the FLASH overflow without sacrificing any module, is the one of setting the binary flash size flag for the W600-PICO board to 2MB = 1 ( see Makefile) - sequence of binary flags: 10100 and changing the line 73 to maintain the script for creating 1MB image, where :

PACKIMG=tools/create_2m_img.sh
becomes :
PACKIMG=tools/create_1m_img.sh

With the above changes the building process:
>make V=s
give us the required images files in the micropython/ports/w60x/build directory.

The arising questions are:

1st - about the implications & /or drawbacks ( if any) of the solution adopted, because the overflowed bytes of the image go to take Flash space dedicated to other storage task.

2nd- To solve the FLASH overflowed, exists a different solution?

3thd - Is this my building problem, may be software depending, or is it a general problem with this port?

4- as it was fixed by the repository maintainers.

The new fls image of 704KB has been successfully uploaded on a W600-PICO board and apparently, until now, I haven't noted any problem.

Thanks in advance for your reply

[Roberthh]

I did a similar thing. The flash space (384k) that is used then was intended for loading packed images (the xxx.bin.gz file) by the loader. So as long as you keep loading .fls files, this space is not used and can safely be used by the firmware.

[federico]

Newly thanks rhh
To see the used process I have posted, as reference, the following video on YouTube:

https://m.youtube.com › watch
W600-PICO Micropython Firmware - YouTube 1:19

[federico]

Hi rhh,
In creating the image files for micropython / ports / w60x from your micropython repository, I got a halt due to w60x / machine / machine_uart.c:

In the 'machine_uart_any' function:
machine_uart.c: undefined reference to "tls_uart_read_avail"

To get around the problem I replaced your machine_uart.c with the same one taken from the WM repository.
The interruption of the process is thus averted, so we have all the images of the w60x port in the build directory.
The wm_w600.fls size is 725 KB.

One (big) pleasant surprise, the user area has quadrupled from 32KB to 128KB.

[Roberthh]

I have a copy of the WM_SDK in my github repository which includes the avail function. At later changes I added the respective modules form the WM-SDk to the W60x source tree. Like for the SPI and watchdog/ticks+delay functions. I could do so with the UART module,
If you take machine_uart.c from the Yichen repository, you will not have the uart.any() method.
Actuall the wm_w600.bin file of my build has 604548 bytes, including a few frozen python files. If you include SSL, it gets larger.
A user area of 128k is surprising. Do you mean the user files space? You can increase that further by increasing the define for FS_EXTENSION in hal/modflash.c. You only have to take care that the sum of files space + the size of the wm_w600.bin file does not exceed 1Mbyte.
If the file space is not sufficient, you can either attach a SD card of an SPI flash chip with up to 16 MByte. That works quite well.

[Roberthh]

I have updated my W600 branch to include wm_uart.c and wm_uart.h, which will give you uart.any() and 300 baud support. If at any time the WM_SDK is changed accordingly, these files can be omitted again. Since there is no public repository for the SDK, I cannot make PRs for that.

[federico]

Hi rhh,
thank you for the broad and competent reply-
I will introduce the suggested changes regarding WMSDK and restore the original machine_uart.c file
The attached images will be able to better clarify that the 255 blocks of 512 are not due to my intervention on the code. My only intervention was the replacement of the machine_uart.c file for the reasons previously described.
I discovered the quadrupled value after opening a REPL session with Mu - as per attached photo. The size of the image files and the SSL configuration in the Makefile are shown in the attachments.

[Roberthh]

There are a few completely unrelated topics here.
- the .fls and .bin file have effectively the same content, but are just differently coded.
- The machine_uart.c code does not have any effect on firmware size or size of the user space, besides the obvious, in that changing the code may increase or decrease the resulting firmware a little bit
- The increase in the user space was cause by a change to hal/modflash.c, where I moved the start of the user space down by 128k now. That is possible since the area used for importing the .bin.gz files cannot used any more due to the increased flash size.

[federico]

I know that doesn't exist any relation between the substitution of machine_uart.c and the user space on the flash - may be that my explanation wasn't sufficiently clear- excuse me-

I confirm that the increase in user space is due to the modification you made to the file hal / modflash.c

After making the updates you suggested:

w60x / hal / wm_uart.c
w60x / wm_uart.h
Makefile

and restored the original from your repository:

w60x / machine / machine_uart.c

no more stops occurred during the building process - see attachment-

A big thank you for your effective support

[federico]

note regarding wm_tool.exe

wm_tool.exe

machine_uart_rhh_OK.png (132.61 KiB) Viewed 4670 times