ch32v307 Modbus + Web UI firmware

[tellurium]

This thread is dedicated to the CH32V307 firmware that implements Modbus master and Web UI, built with Mongoose Libary (https://github.com/cesanta/mongoose/)

Steps to build & try (on Mac, Windows, Linux):
1. Setup build environment: https://mongoose.ws/documentation/tutorials/tools/ , most notably - symlink support for git & make
2. Install riscv toolchain, e.g. on Mac `brew install riscv-gnu-toolchain`
3. clone mongoose repo: git clone https://github.com/cesanta/mongoose/
4. Go to examples/wch/ch32v307-make-baremetal-builtin, start command prompt/terminal, run "make"
5. Attach serial console to USART1: TX pin A9, baud rate 115200. Use serial converter
6. Observe logs, look at the obtained IP address (see below for logs example)
7. Point your browser at that IP address

Example console output:

412    2 net_builtin.c:197:onstatechang READY, IP: 192.168.2.78
417    2 net_builtin.c:198:onstatechang        GW: 192.168.2.1
41d    2 net_builtin.c:199:onstatechang       MAC: 02:38:9a:a3:39:e3
423    2 main.c:107:main                Initialising application...
429    3 net.c:195:mg_listen            1 0 http://0.0.0.0
42e    2 main.c:110:main                Starting event loop
7dd    2 main.c:35:timer_fn             Ethernet: ready, IP: 192.168.2.78, rx:4, tx:3, dr:0, er:0
bc5    2 main.c:35:timer_fn             Ethernet: ready, IP: 192.168.2.78, rx:5, tx:3, dr:0, er:0
fad    2 main.c:35:timer_fn             Ethernet: ready, IP: 192.168.2.78, rx:5, tx:3, dr:0, er:0

Current firmware size: ~90k on flash.
Screenshot attached.

Note: this firmware can be also run on a Windows/Linux/Mac workstation: cd examples/modbus-dashboard && make

The MQTT functionality is not yet working.
Saving configuration persistently on a flash is not yet working either.

Feedback is welcome, please let me know what features you'd like to see.

[ali_asadzadeh]

thanks tellurium for sharing,
But I can not compile the code on win11, I will get these errors

riscv-none-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
Cannot create temporary file in C:\Windows\: Permission denied
make: *** [Makefile:25: firmware.elf] Error 127

[bingo600]

thanks tellurium for sharing,
But I can not compile the code on win11, I will get these errors

riscv-none-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
Cannot create temporary file in C:\Windows\: Permission denied
make: *** [Makefile:25: firmware.elf] Error 127

Didn't the answer in the other thread solve it ?
https://www.eevblog.com/forum/microcontrollers/ch32v307-risc-v-minicore-with-ethernet/msg5190546/#msg5190546

[tellurium]

thanks tellurium for sharing,
But I can not compile the code on win11, I will get these errors

Yeah, as bingo600 mentioned, try a suggested fix: create a directory c:\temp and set a system-wide environment variable TMP=c:\temp

I am attaching .bin and .elf files of the latest firmware to the first post.

[ali_asadzadeh]

I have done it, Still no luck :'(

make
riscv-none-elf-gcc main.c mongoose.c vendor/system_ch32v30x.c vendor/startup_ch32v30x_D8C.S -W -Wall -Wextra -Wno-error -Wundef -Wshadow -Wdouble-promotion -Wformat-truncation -fno-common -Wconversion -Wno-sign-conversion -ffunction-sections -fdata-sections  -march=rv32imafc -mabi=ilp32f  -DSYSCLK_FREQ_144MHz_HSE -I. -Ivendor -g3 -Os  -T vendor/link.ld -nostartfiles --specs=nano.specs  -lc -lgcc -Wl,--gc-sections  -o firmware.elf
Cannot create temporary file in C:\Windows\: Permission denied
make: *** [Makefile:25: firmware.elf] Error 127

[ejeffrey]

Try changing TEMP and TMPDIR as well.  Also check at the command line that the variables are set as you expect, windows has both system and user environment variables with the latter overriding the former.  Finally check that you can write files in the temp directory chosen.

[martinribelotta]

I have done it, Still no luck :'(

Ho! I see the problem, you don't have administrator permissions and the GCC are trying to write to C:\WINDOWS\TMP.

Change TEMP to directory that you can write as a normal user (I think that TMP and TEMP environment vars must be contains the same value)

[bingo600]

According to the gcc docs
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html

Setting env var : TMPDIR
Would be the one to set for GCC

As already suggested above

But i do agree that i would set all the "TMP" env vars to ie. C:\TMP or C:\TEMP
Not : C:\WINDOWS\TMP

[ali_asadzadeh]

Still the same problem

[martinribelotta]

Still the same problem

Try to execute

Code: [Select]

echo $TMPDIR
echo $TEMP
echo $TMP

In MinGW terminal... maybe the /etc/profile has another configuration overwriting the system one.

[bingo600]

@tellurium
Jyst FYI ...

I tried mongoose today, and was scratching my head a lot ... Using linux mint
It didn't work.

I have this board & programmer
https://www.aliexpress.com/item/1005005021450761.html
CH32V307 EVT (by SCDZ, close to official W.CH board)

I tried a "blinky" ... worked
And then i discovered that the programmer also registers as /dev/ttyACM0
I fired up putty @115200 on ttyACM0

When programmed i see this

Code: [Select]

0      2 main.c:88:main                 Starting, CPU freq 144 MHz
6      2 main.c:102:main                MAC: 02:38:32:38:39:e3. Waiting for IP...
3f5    2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
7dd    2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
bc5    2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
fad    2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
1395   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
177d   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
1b65   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
1f4d   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
2335   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
271d   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
2b05   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
2eed   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
32d5   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
36bd   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
3aa5   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
3e8d   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0
4275   2 main.c:35:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0

Nothing happened besides the above ....

Then i disconnected the Ethernet Jack , and reconnected
And it saw a mac address , and after a few seconds it got an IP

That method works .... Sometimes


What always work , is to press reset when it "doesn't see (show) the ethernet MAC.

Code: [Select]

0      2 main.c:88:main                 Starting, CPU freq 144 MHz
6      2 main.c:102:main                MAC: 02:38:32:38:39:e3. Waiting for IP...
3ee    3 stm32.c:193:mg_tcpip_driver_st Link is 10M half-duplex
3f3    1 net_builtin.c:202:onstatechang Link up
3f7    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
3ff    2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:1, dr:0, er:0
7d6    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
7dd    2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:2, dr:0, er:0
bbe    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
bc5    2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:3, dr:0, er:0
fa6    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
fad    2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:4, dr:0, er:0
138e   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
1395   2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:5, dr:0, er:0
1776   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
177d   2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:1, tx:6, dr:0, er:0
1b5e   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
1b65   3 net_builtin.c:281:tx_dhcp_requ DHCP req sent
1b6a   2 net_builtin.c:407:rx_dhcp_clie Lease: 6210 sec (6217)
1b70   2 net_builtin.c:197:onstatechang READY, IP: 10.117.10.210
1b75   2 net_builtin.c:198:onstatechang        GW: 10.117.10.1
1b7b   2 net_builtin.c:199:onstatechang       MAC: 02:38:32:38:39:e3
1b81   2 main.c:35:timer_fn             Ethernet: ready, IP: 10.117.10.210, rx:4, tx:9, dr:0, er:0
1b8a   2 main.c:107:main                Initialising application...
1b90   3 net.c:195:mg_listen            1 0 http://0.0.0.0
1b95   2 main.c:110:main                Starting event loop
1f4d   2 main.c:35:timer_fn             Ethernet: ready, IP: 10.117.10.210, rx:4, tx:9, dr:0, er:0



Code: [Select]

1adbd  2 main.c:35:timer_fn             Ethernet: ready, IP: 10.117.10.210, rx:4, tx:8, dr:0, er:0
1b1a5  2 main.c:35:timer_fn             Ethernet: ready, IP: 10.117.10.210, rx:4, tx:8, dr:0, er:0
1b58d  2 main.c:35:timer_fn             Ethernet: ready, IP: 10.117.10.210, rx:4, tx:8, dr:0, er:0
1b975  2 main.c:35:timer_fn             Ethernet: ready, IP: 10.117.10.210, rx:4, tx:8, dr:0, er:0
1bd5d  2 main.c:35:timer_fn             Ethernet: ready, IP: 10.117.10.210, rx:4, tx:8, dr:0, er:0
1c145  2 main.c:35:timer_fn             Ethernet: ready, IP: 10.117.10.210, rx:4, tx:8, dr:0, er:0
0      2 main.c:88:main                 Starting, CPU freq 144 MHz
6      2 main.c:102:main                MAC: 02:38:32:38:39:e3. Waiting for IP...
3ee    3 stm32.c:193:mg_tcpip_driver_st Link is 10M half-duplex
3f3    1 net_builtin.c:202:onstatechang Link up
3f7    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
3ff    2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:1, dr:0, er:0
7d6    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
7dd    2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:2, dr:0, er:0
bbe    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
bc5    2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:3, dr:0, er:0
fa6    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
fad    2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:4, dr:0, er:0
138e   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
1395   2 main.c:35:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:5, dr:0, er:0

I see same issue when doing a Power Reset.
It doesn't see the link-up (Ethernet link) , until i press Reset button.


Does the ethernet link check start too fast ??

Edit:
I have attached my Makefile (had to append .txt - to upload)

It uses the linux (wch clone) programmer : https://github.com/cnlohr/ch32v003fun/tree/master/minichlink
"clone" , build , and copy to "somewhere on path"


Note: There seems to be an issue w minichlink - It resets the chip to 288K/32K  Flash/Ram partitioning
But ATM that's fine for mongoose.

https://blog.dan.drown.org/ch32v307-dev-board-part-5/

I finally figured out that it was how minichlink was talking with the debugger. If I use wlink, the option bytes don't get overwritten. But wlink leaves my debugger hardware in some unknown state and I have to power cycle it to get the debugger working again. I've opened a github issue, and I want to try reverse engineering the WCH-LinkE protocol to see if I can figure out how to fix this.

There's a hack/fix here
https://www.eevblog.com/forum/microcontrollers/ch32v307-risc-v-minicore-with-ethernet/msg5195862/#msg5195862


Edit2:
ddrown's  lwip demo also needs an extra button reset to get an ip.
So it could be board related ... I'm using a HP 1820 switch, and have no issues w. that

/Bingo

[ali_asadzadeh]

Try to execute
Code: [Select]
echo $TMPDIR
echo $TEMP
echo $TMP

I have tired, here is the results

[SiliconWizard]

I guess you haven't tried adding the '-pipe' option to CFLAGS as I have suggested earlier, to circumvent this temp files altogether?

[bingo600]

Try to execute
Code: [Select]
echo $TMPDIR
echo $TEMP
echo $TMP

I have tired, here is the results

Why doesn't $TMPDIR point at the same as $TMP
Does c:\temp exist

[tellurium]

I have this board & programmer
https://www.aliexpress.com/item/1005005021450761.html
CH32V307 EVT (by SCDZ, close to official W.CH board)

I don't have that board, ordered and expecting it to arrive in a couple of weeks.

I use this one:
https://www.aliexpress.com/item/1005004350410929.html

I don't know who makes those boards. They are set to 32k RAM / 288K flash by default.
To reprogram it, I press boot + reset buttons, then use "wchisp flash" command. The wchisp is this one: https://github.com/ch32-rs/wchisp

This board always picks up and IP from DHCP , I haven't seen an issue that you described. Will test on the WCH's board when it arrives.


Option byte notes:

I would like to set the board to the 96k RAM / 224k flash configuration, but unfortunately wchisp does not yet know how to set option bytes.
I can do in in the firmware code, but it needs a bootstrapping phase:
1. Add a code to the firmware that checks option byte to 96/224
2. Build a firmware with 32/288 linker script, flash & run it. This is necessary cause running a 96/224 linked firmware won't work if chip is configured to 32/288
3. Rebuild the firmware wirh 96/224 linker script, and flash it again: now chip should be 96/224

That works, I've tried that, but it is kinda cumbersome and confusing. I wish option bytes can be set by a utility before flashing. Maybe wchlink utility can do it, I don't have one yet, will test when it arrives.

[bingo600]

I wish option bytes can be set by a utility before flashing. Maybe wchlink utility can do it, I don't have one yet, will test when it arrives.

I just hacked Ram partitioning into minichlink

See
https://www.eevblog.com/forum/microcontrollers/ch32v307-risc-v-minicore-with-ethernet/msg5197074/#msg5197074

Code: [Select]

mongose/mongoose/examples/wch/ch32v307-make-baremetal-builtin$ make flash
minichlink -K 96 -a -w firmware.bin 0x08000000 -b
Found WCH Link
WCH Programmer is CH549 version 2.10
Chip Type: 307
CH32V30x or CH32V20x MCU detected. Using binary blob write for operation.
Setup success
Flash Storage: 288 kB
Part UUID    : 26-cb-d9-2c-38-32-38-3b
PFlags       : e3-39-e3-39
Part Type (B): 30-70-05-18
Read protection: disabled
Interface Setup
MCU Ram set to 96KB on next boot
Image written.


But my board still requires an extra reset ...

/Bingo

[bingo600]

I don't have that board, ordered and expecting it to arrive in a couple of weeks.

Thanx for the support.

I'm just a "hobbyist"

I have only used the wchlink or wclink-e dongle to program my board.

I have no idea if the rust program supports my board or dongle.
I don't have that addon PCB with the USBC programmer/debugger , just the dongle(s).

I suppose there's no DFU loader on the CHIP USB's ?? ... Like on a STM32F4 ??


/Bingo

[bingo600]

I just tried to connect USB , and the Boot0 key.
I could program via wchlink wchisp (rust binary) ....

But i still need to do a "button reset" , in order to get an IP.

So it's prob not the programmer.

/Bingo

[tellurium]

Quick update:

1. Still using 32k ram / 288k flash in the linker file. That should work also for devices configured for larger RAM, just not all RAM would be utilized. I'll try to use Bingo's whlink update to set device config (when I'll get a board with wchlink). If that works, I'll switch the build for larger RAM, perhaps 64/256.

2. Added ability to save configuration on flash permanently - so now it survives reboots. The code uses the sector that follows a mapped 320k area, no wear levelling is done. Attempted to use littlefs on the whole "unmapped" flash region - but littlefs eats too much RAM, so went for a simple sector write instead

3. Followed SiliconWizard's finding about bss. Hand-crafted linker script considering that, with pieces taken from the wch's SDK. Here's current linker script file for the project: https://github.com/cesanta/mongoose/blob/master/examples/wch/ch32v307-make-baremetal-builtin/link.ld

4. Attached an updated binary download to the first post (ch32v307.modbus.firmware.2023-12-01.zip)

[bingo600]

I just noticed a much different 307 demo now.
And i haven't saved the old source ....


Well strange below

I programmed with the minichlink , that's supposed to set 96K Ram

On 1'st Boot (after being flashed) it shows correct

Code: [Select]

0      2 main.c:100:main                Starting, CPU freq 144 MHz
5      2 main.c:103:main                Heap size: 17440 bytes
b      2 main.c:108:main                RAM/FLASH configuration: 96/224      <-------------------



On Reset (Button) it changed to 32K Ram ....

Code: [Select]

12     2 main.c:100:main                Starting, CPU freq 144 MHz
17     2 main.c:103:main                Heap size: 17440 bytes
1d     2 main.c:108:main                RAM/FLASH configuration: 32/288  <-------------------
24     2 main.c:124:main                MAC: 02:38:32:38:39:e3. Waiting for IP...
40c    3 stm32.c:193:mg_tcpip_driver_st Link is 10M half-duplex
411    1 net_builtin.c:202:onstatechang Link up
415    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
7f4    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
bdc    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
fc4    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
13ac   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
1794   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
179b   3 net_builtin.c:281:tx_dhcp_requ DHCP req sent
17a0   2 net_builtin.c:407:rx_dhcp_clie Lease: 6884 sec (6890)
17a6   2 net_builtin.c:197:onstatechang READY, IP: 10.117.10.210
17ab   2 net_builtin.c:198:onstatechang        GW: 10.117.10.1
17b1   2 net_builtin.c:199:onstatechang       MAC: 02:38:32:38:39:e3
17b7   2 main.c:129:main                Initialising application...
17bd   3 net.c:195:mg_listen            1 0 http://0.0.0.0:8000
17c3   3 net.c:195:mg_listen            2 0 http://0.0.0.0/
17c8   3 net.c:195:mg_listen            3 0 https://0.0.0.0/
17cd   2 main.c:133:main                Starting event loop
17d2   3 net.c:171:mg_connect           4 -1 udp://time.google.com:123
17d9   3 net.c:171:mg_connect           5 -1 udp://8.8.8.8:53
17de   3 net_builtin.c:1002:mg_connect_ 5 10.117.10.210:32768 -> 8.8.8.8:53
2392   3 net.c:148:mg_close_conn        4 -1 closed


Wonder if that's the programmer ?
Can you set ram partitioning , so it's not written/saved to flash

Well if i comment out :

Code: [Select]

  //if (mode != 3) set_ram_size(2), mg_device_reset();
It will always show

Code: [Select]

b      2 main.c:108:main                RAM/FLASH configuration: 96/224      <-------------------

And i have issues getting an ip (DHCP) .... Also after a button Reset.
The button reset worked 100% on the old vers.

And so did a NVIC_Reset (instead of Button Reset) in the "Timer loop" after 10 loops of "down state" , on the old vers.

/Bingo

[tellurium]

Wonder if that's the programmer ?

Ah, that's just the firrmware code flips the option byte back to 32/388, you figured it out right.
Disable it by commenting out this line:

https://github.com/cesanta/mongoose/blob/7f8cdf1e79f609e834f59f247b69b51bc7444c9e/examples/wch/ch32v307-make-baremetal-builtin/main.c#L109

Then, reprogram the board again to 96/224
And, change the link.ld to 96/224 here:
https://github.com/cesanta/mongoose/blob/7f8cdf1e79f609e834f59f247b69b51bc7444c9e/examples/wch/ch32v307-make-baremetal-builtin/link.ld#L3-L4

Then your board should work on 96/224 configuration.
See what is the log message about heap size, it should be somewhat less than 96k

Without changling link.ld, you're still using little ram, see


17     2 main.c:103:main                Heap size: 17440 bytes


This heap size of ~17k is 32k minus static DMA Ethernet buffers.

[bingo600]

Hmmm ... You moved the linkerfile (used) from vendor to main dir, But kept the vendor linkerfile .... 
At first I did do the 224/96 adaptation at the beginning but in vendor linker file, and nothing happened ...
I have adapted makefile to vendor ld file again

Now i'm back to : It works after a button reset 

Code: [Select]

▒0      2 main.c:100:main                Starting, CPU freq 144 MHz
5      2 main.c:103:main                Heap size: 82848 bytes
b      2 main.c:108:main                RAM/FLASH configuration: 96/224
12     2 main.c:124:main                MAC: 02:38:32:38:39:e3. Waiting for IP...
0      2 main.c:100:main                Starting, CPU freq 144 MHz
5      2 main.c:103:main                Heap size: 82848 bytes
b      2 main.c:108:main                RAM/FLASH configuration: 96/224
12     2 main.c:124:main                MAC: 02:38:32:38:39:e3. Waiting for IP...
3fa    3 stm32.c:193:mg_tcpip_driver_st Link is 10M half-duplex
3ff    1 net_builtin.c:202:onstatechang Link up
403    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
7e2    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
bca    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
fb2    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
139a   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
1782   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
1789   3 net_builtin.c:281:tx_dhcp_requ DHCP req sent
178e   2 net_builtin.c:407:rx_dhcp_clie Lease: 7044 sec (7050)
1794   2 net_builtin.c:197:onstatechang READY, IP: 10.117.10.210
1799   2 net_builtin.c:198:onstatechang        GW: 10.117.10.1
179f   2 net_builtin.c:199:onstatechang       MAC: 02:38:32:38:39:e3
17a5   2 main.c:129:main                Initialising application...
17ab   3 net.c:195:mg_listen            1 0 http://0.0.0.0:8000
17b1   3 net.c:195:mg_listen            2 0 http://0.0.0.0/
17b6   3 net.c:195:mg_listen            3 0 https://0.0.0.0/
17bb   2 main.c:133:main                Starting event loop
17c0   3 net.c:171:mg_connect           4 -1 udp://time.google.com:123
17c7   3 net.c:171:mg_connect           5 -1 udp://8.8.8.8:53
17cc   3 net_builtin.c:1002:mg_connect_ 5 10.117.10.210:32768 -> 8.8.8.8:53



And i did a NVIC_Reset if link was down ...
That got the board to get "link-up" , and a DHCP IP. Wo. any intevention

Code: [Select]

static void timer_fn(void *arg) {
  gpio_toggle(LED_PIN);                                  // Blink LED_PIN
  struct mg_tcpip_if *ifp = arg;                         // And show
  const char *names[] = {"down", "up", "req", "ready"};  // network stats

  if(0 == ifp->state)
  {
    NVIC_SystemReset();
  }
  return;
  MG_INFO(("Ethernet: %s, IP: %M, rx:%u, tx:%u, dr:%u, er:%u",
           names[ifp->state], mg_print_ip4, &ifp->ip, ifp->nrecv, ifp->nsent,
           ifp->ndrop, ifp->nerr));
}

Code: [Select]

0      2 main.c:105:main                Starting, CPU freq 144 MHz            <---------------- Programmer/Flash-done Boot
5      2 main.c:108:main                Heap size: 82848 bytes
b      2 main.c:113:main                RAM/FLASH configuration: 96/224
12     2 main.c:129:main                MAC: 02:38:32:38:39:e3. Waiting for IP...
0      2 main.c:105:main                Starting, CPU freq 144 MHz            <---------------- NVIC_Reset
5      2 main.c:108:main                Heap size: 82848 bytes
b      2 main.c:113:main                RAM/FLASH configuration: 96/224
12     2 main.c:129:main                MAC: 02:38:32:38:39:e3. Waiting for IP...
3fa    3 stm32.c:193:mg_tcpip_driver_st Link is 10M half-duplex
3ff    1 net_builtin.c:202:onstatechang Link up
403    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
7e2    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
bca    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
fb2    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
139a   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
1782   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
1b6a   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:39:e3
1b71   3 net_builtin.c:281:tx_dhcp_requ DHCP req sent
1b76   2 net_builtin.c:407:rx_dhcp_clie Lease: 5629 sec (5636)
1b7c   2 net_builtin.c:197:onstatechang READY, IP: 10.117.10.210
1b81   2 net_builtin.c:198:onstatechang        GW: 10.117.10.1
1b87   2 net_builtin.c:199:onstatechang       MAC: 02:38:32:38:39:e3
1b8d   2 main.c:134:main                Initialising application...
1b93   3 net.c:195:mg_listen            1 0 http://0.0.0.0:8000
1b99   3 net.c:195:mg_listen            2 0 http://0.0.0.0/
1b9e   3 net.c:195:mg_listen            3 0 https://0.0.0.0/
1ba3   2 main.c:138:main                Starting event loop
1ba8   3 net.c:171:mg_connect           4 -1 udp://time.google.com:123
1baf   3 net.c:171:mg_connect           5 -1 udp://8.8.8.8:53
1bb4   3 net_builtin.c:1002:mg_connect_ 5 10.117.10.210:32768 -> 8.8.8.8:53
2768   3 net.c:148:mg_close_conn        4 -1 closed



Now it doesn't need the Button Reset

Btw:
Just an hunch.
The Board missing Ethernet link on POR "issue" ....
Maybe it could be power related  (I power via the wchlink dongle) ... If i disconnect the dongle--> board cable for a short while (1 sec or so) , and the reconnect.
It does make the link ... If i disconnect for 5 sec or more , it doesn't.

I'm not an EE , but does the MAC-Jack pull a lot of power to energize ?
Maybe the dongle can't supply on first boot.

I don't have a PSU beside me , but maybe i can solder ?? (isn't there a limit on how much capacitance you can put behind usb ?) ... 10uF or ?? on the board.
I see several of the boards have 10uF before and after the LDO , and other have 10uF before & 2.2uF after.
Judging from the size of my cap's , i think i have 10uF & 2.2uF on mine.

[ali_asadzadeh]

my ch32v307V-R1-1V0 board has WCH-Link Utility onboard, and Finlay I managed to compile the code, I think the msys2 was conflicting with this new installation

After compiling the code I used the  WCH-LinkUtility to load the bin file and program the board, the uart output is something like

288    2 main.c:100:main                Starting, CPU freq 144 MHz
28d    2 main.c:103:main                Heap size: 82976 bytes
293    2 main.c:108:main                RAM/FLASH configuration: 96/224

I think the board would crash and do not move forward, after plunging and unplugging the board from power, there is no UART output again :'( :'(, I should reprogram the board with some examples in mounriver studio to be able to see the UART output again,

what am I doing wrong? is there a way to debug the code?

[bingo600]

my ch32v307V-R1-1V0 board has WCH-Link Utility onboard, and Finlay I managed to compile the code, I think the msys2 was conflicting with this new installation

After compiling the code I used the  WCH-LinkUtility to load the bin file and program the board, the uart output is something like

288    2 main.c:100:main                Starting, CPU freq 144 MHz
28d    2 main.c:103:main                Heap size: 82976 bytes
293    2 main.c:108:main                RAM/FLASH configuration: 96/224

I think the board would crash and do not move forward, after plunging and unplugging the board from power, there is no UART output again :'( :'(, I should reprogram the board with some examples in mounriver studio to be able to see the UART output again,

what am I doing wrong? is there a way to debug the code?

Your output looks correct to me.

But ....
Did you use the linker file from main-dir or the one from the vendor dir ?
The one from main dir prob. has to be adapted to 96K Ram.

Did you have the Bord LAN Jack connected to a working switchport ?
 
Have you connected the "Blinky led" ?
See LED2 (top of main.c) for port/pin  - That one should/would blink to show mongoose is running.


Could the Board Com-Port have switched to another number ??

[ali_asadzadeh]

Your output looks correct to me.

It's like yours but it does not print more stuff to the console,

But ....
Did you use the linker file from main-dir or the one from the vendor dir ?
The one from main dir prob. has to be adapted to 96K Ram.

I have used the linker file with is beside the mian.c file

Have you connected the "Blinky led" ?
See LED2 (top of main.c) for port/pin  - That one should/would blink to show mongoose is running.

Yes, and it's do not do anything, I think the board would crash after doing some stuff, since I do not know how to debug the code, I can not say what's the buggy function.

[bingo600]

Your output looks correct to me.

It's like yours but it does not print more stuff to the console,

But ....
Did you use the linker file from main-dir or the one from the vendor dir ?
The one from main dir prob. has to be adapted to 96K Ram.

I have used the linker file with is beside the mian.c file

Have you connected the "Blinky led" ?
See LED2 (top of main.c) for port/pin  - That one should/would blink to show mongoose is running.

Yes, and it's do not do anything, I think the board would crash after doing some stuff, since I do not know how to debug the code, I can not say what's the buggy function.

You have to modify the linkerfile to 96KB Ram
Either edit the one besides main , or copy the one from the vendor dir to the one in the main dir

[ali_asadzadeh]

Now, it starts to work, is there any chance that we can add FreeRTOS to it? also Is there a way to debug the code?

[bingo600]

Now, it starts to work, is there any chance that we can add FreeRTOS to it? also Is there a way to debug the code?

Why would you add FreeRTOS to mongoose

[ali_asadzadeh]

Why would you add FreeRTOS to mongoose

I need it to implement some tasks, also I have tested the demo app with ModbusDoctorV2 app, and it can not connect to the device using the 502 port, it only accepts port 80 But it would not respond back with modbus messages, I have tried the 192.168.1.3 and 192.168.1.100 IP's, the board would boot with 192.168.1.3 IP in my case.

[ali_asadzadeh]

I'm trying to port mongoose to mounriver studio, so at least we can debug it, Here is the progress till now, I have used FreeRTOS,

And this is the output uart

SystemClk:144000000
ChipID:30700518
FreeRTOS Kernel Version:V10.4.6
0      2 main.c:159:task2_task          Starting, CPU freq 144 MHz
2      2 main.c:162:task2_task          Heap size: 57224 bytes
5      2 main.c:167:task2_task          RAM/FLASH configuration: 96/224

when the program would hit this line
mg_tcpip_init(&mgr, &mif);

It would not go any further  and mounriver would not show the source file!!! But the task 1 is doing it's job, do you have any Idea what can cause this problem?


you can get the ported project at this link
https://www.file.io/GnAr/download/DYIfQcliAdGX

[tellurium]

It would not go any further  and mounriver would not show the source file!!! But the task 1 is doing it's job, do you have any Idea what can cause this problem?

Comment out "#define MG_ENABLE_LINES 1" in the mongoose_custom.h and rebuild. Then it should show the source.
Give mongoose task at least 8k of stack space.

[ali_asadzadeh]

Thanks tellurium
Now it shows the sources, But it would stuck at this line
it's line 9309 in mongoose.c

while ((ETH->DMABMR & MG_BIT(0)) != 0) (void) 0;  // Wait until done

[tellurium]

Thanks tellurium
Now it shows the sources, But it would stuck at this line
it's line 9309 in mongoose.c

I have installed MRS, created a basic printf project, and moved mongoose code from the bare metal example - works for me.
Must be something with initialisation, I suspect ethernet MAC/PHY controller init is missing.

Could you share your MRS project please?

[tellurium]

We recently added a built-in TLS1.3 stack to Mongoose Library (server part for now).

I did an experimental build of the modbus firmware with TLS enabled.
Didn't manage to get it to work on 32k RAM configuration - too tight!
Note that the browser spawns multiple (~5) connections to speed up HTML GUI rendering, meaning that the box gets hit by ~5 simultaneous TLS connections, which are both RAM and CPU hungry.

But lo and behold, with 64k RAM configuration, it works! Flaky sometimes, but works.
To build with TLS, change vendor/link.ld to 256/64 configuration, then "make CFLAGS_EXTRA="-DMG_TLS=MG_TLS_BUILTIN".
Screenshot attached.

TLS-enabled firmware build is attached to the 1st post.

[SiliconWizard]

How much Flash do you use? You know you can get up to 128KB RAM with the proper config - it'll limit the available code memory to 192KB though. Might still be workable!

[tellurium]

How much Flash do you use? You know you can get up to 128KB RAM with the proper config - it'll limit the available code memory to 192KB though. Might still be workable!

This current TLS-enabled build is 110344 bytes, which is below half of the available flash size (256 / 2 = 128k). Plenty of room is there yet!
Meaning, even firmware update is possible.

So, on this CH32V307, it is possible to create a TLS-enabled Web UI dashboard with firmware update functionality.
The flash content would be wide open of course, but still.

[SiliconWizard]

The memory layout of this chip is documented (sorta) but not really advertised. Not sure why. So people tend not to know, or assume that may not work, and so on.

To sum up again, the CH32V307 has:
- A total of 320KB RAM
- A total of 480KB Flash

Due to how the memory is mapped for code execution (which uses some amount of RAM to cache access, which I suspect is just a full copy of your code Flash content at boot), you only have access to a maximum of 288KB of code memory (in this case, with a data memory of 32KB), or a maximum of 192KB code memory (with a data memory of 128KB), and a couple combinations in between.

The calculation is simple, available code memory = 320KB - available data memory. That makes it obvious all code is loaded from Flash to RAM at boot. No code ever executes directly from Flash, which is why the chip has a guaranteed zero-wait-state access to code memory at all system clock frequencies.

Besides, anything in Flash above the max code memory size in a given configuration is usable for anything else up to the 480KB limit. So in a 192KB "Flash"/128KB "RAM" configuration, you still have 480KB - 192KB (288KB !) of Flash usable to store anything, a second copy of the whole code, user data, etc.

That gives a lot more possibilities that many people appear to think when exposed to the CH32V307.
Why WCH doesn't advertise this more is unknown to me. It's fully (albeit not overly detailed) documented in the DS and RM documents.
But note that if you base your impression of the chip on just intrroduction parts of the docs and the provided SDK and examples, you'll miss out on a lot of stuff. The examples they provide are very limited and only show a fraction of the possibilities, and that's true for almost all aspects of the chip, from memory to USB.

[tellurium]

Would this be a correct summary?


Possible RAM/Flash configurations for CH32V307:

32k data / 288k code:   |-32-|----------288------|
64k data / 256k code:   |-64---|--------256------|
96k data / 224k code:   |-96-----|------224------|
128k data / 192k code:  |-128-------|---192------|

                        |<--------- 320k ------->|

This configuration is stored in the flash option bytes.
Here is a function that sets the required configuration:
https://github.com/cesanta/mongoose/blob/3965aecfd473cbd70027b636492bb19b615eadd4/examples/wch/ch32v307-make-baremetal-builtin/hal.h#L121-L136

Flash is mapped at address 0x8000000 and 0x0, and is of size 480k.
There is available flash "scratch space" of size "480k - codesize" that
can be used for persistent storage. The initial "code" portion gets copied into RAM for execution.

   0x0
   |------ code -----|------------- storage space -------|

   |<---------------------- 480k ----------------------->|

[SiliconWizard]

Yes, the only thing to add probably is that as far as Flash address mapping goes, while it is indeed remapped at address 0 for *reading*, I think you still need to use addresses starting at 0x8000000 for *writing* to Flash.

[bingo600]

I have this board & programmer
https://www.aliexpress.com/item/1005005021450761.html
CH32V307 EVT (by SCDZ, close to official W.CH board)

I don't have that board, ordered and expecting it to arrive in a couple of weeks.

@tellurium
Did you ever get the board above ?

/Bingo

[tellurium]

@tellurium
Did you ever get the board above ?
/Bingo

Yes I did! The latest change to the code I've done with that board.

[bingo600]

@tellurium
Did you ever get the board above ?
/Bingo

Yes I did! The latest change to the code I've done with that board.

I just tried the latest code , and i still have that ethernet issue ....
After programming or a POR it just "hangs here"

Code: [Select]

2b19   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
2f01   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
32e9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
36d1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
3ab9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
3ea1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
4289   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
4671   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
4a59   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
4e41   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
5229   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051
5611   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/8051


If i press reset ... It will get an ip

Or if i test for ethernet link , and do a NVIC Reset. It will also get an ip.

Code: [Select]

static void timer_fn(void *arg) {
  gpio_toggle(LED_PIN);                                  // Blink LED_PIN
  struct mg_tcpip_if *ifp = arg;                         // And show
  const char *names[] = {"down", "up", "req", "ready"};  // network stats
  MG_INFO(("Ethernet: %s, IP: %M, rx:%u, tx:%u, dr:%u, er:%u RAM: %lu/%lu",
           names[ifp->state], mg_print_ip4, &ifp->ip, ifp->nrecv, ifp->nsent,
           ifp->ndrop, ifp->nerr, hal_ram_used(), hal_ram_free()));

#if 1
  if(0 == ifp->state)
  {
    NVIC_SystemReset();
  }
#endif

}

Wonder if my board is strange ??
I'm still waiting for a some of "your old" boards from Ali ....


Edit: I'm programming & powering via a - WCHLink USB Dongle (the cheap one wo buttons) , that came w. the set
Using minichlink with my patches for Ram/Rom assignment
https://www.eevblog.com/forum/microcontrollers/ch32v307-risc-v-minicore-with-ethernet/msg5197074/#msg5197074

Attached the modified makefile  (just 3 lines)



Edit2:
I tried to add 22uF and even 100uF to the 5v rail  ...  Same issue

Edit3:
The reason i'm not doing wireshark traces, is that the "link is down" ....

/Bingo

[tellurium]

I consistently get everything working after flashing.
Here is what I am doing:

Terminal1 - building & flashing

Code: [Select]

$ git clone https://github.com/cesanta/mongoose
$ cd mongoose/examples/wch/ch32v307-make-baremetal-builtin
$ make CFLAGS_EXTRA='-Wl,--defsym -Wl,RAM_64K=1' clean all
$ wlink flash firmware.elf

Terminal2 - reading serial logs

Code: [Select]

$ cu -l /dev/cu.usb* -s 115200                                                                                           
Connected.                                                                                                                 
0      2 main.c:46:main                 Starting, CPU freq 144 MHz                                                         
5      2 main.c:51:main                 RAM/FLASH configuration: 64/256                                                   
c      2 main.c:55:main                 Heap size: 48032 bytes. RAM: used 1032, free 50823                                 
14     3 stm32f.c:152:mg_tcpip_driver_s PHY ID: 0x00 0x00                                                                 
19     2 main.c:70:main                 MAC: 02:50:5c:7e:39:e3. Waiting for IP...                                         
401    3 stm32f.c:201:mg_tcpip_driver_s Link is 10M half-duplex                                                           
406    1 net_builtin.c:202:onstatechang Link up                                                                           
40a    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:5c:7e:39:e3                                     
412    3 net_builtin.c:281:tx_dhcp_requ DHCP req sent                                                                     
417    2 main.c:26:timer_fn             Ethernet: req, IP: 0.0.0.0, rx:3, tx:2, dr:0, er:0 RAM: 10860/40787               
420    2 net_builtin.c:408:rx_dhcp_clie Lease: 86400 sec (86401)                                                           
426    2 net_builtin.c:197:onstatechang READY, IP: 192.168.2.86                                                           
42c    2 net_builtin.c:198:onstatechang        GW: 192.168.2.1                                                             
431    2 net_builtin.c:199:onstatechang       MAC: 02:50:5c:7e:39:e3                                                       

That I am getting consistently. I cannot reproduce that behavior you're talking about.
Note that the CFLAGS_EXTRA='-Wl,--defsym -Wl,RAM_64K=1' build flag is used to build for 256/64 flash/ram configuration, which is the default for that board.

I got my board from Elektor, unpacked and connected to my USB hub with Ethernet port, no modifications/alterations made.

[bingo600]

I consistently get everything working after flashing.
Here is what I am doing:

Terminal1 - building & flashing

Code: [Select]

$ git clone https://github.com/cesanta/mongoose
$ cd mongoose/examples/wch/ch32v307-make-baremetal-builtin
$ make CFLAGS_EXTRA='-Wl,--defsym -Wl,RAM_64K=1' clean all
$ wlink flash firmware.elf
                                       


That I am getting consistently. I cannot reproduce that behavior you're talking about.
Note that the CFLAGS_EXTRA='-Wl,--defsym -Wl,RAM_64K=1' build flag is used to build for 256/64 flash/ram configuration, which is the default for that board.

I got my board from Elektor, unpacked and connected to my USB hub with Ethernet port, no modifications/alterations made.

I didn't use any extra flags , but gave it 96K Ram on flashing.
I'll try your "extra's"

/Bingo 

[bingo600]

I tried with the EXTRA def's , and no luck ....

But then i tried with another switch

My original switch is a HP-1820 8-port , and i switched to a Dlink DGS-1100-08 V2
Now it's getting link , but it has to do a lot of "link down" first

Code: [Select]

0      2 main.c:46:main                 Starting, CPU freq 144 MHz
5      2 main.c:51:main                 RAM/FLASH configuration: 64/256
c      2 main.c:55:main                 Heap size: 48032 bytes. RAM: used 1032, free 50823
14     3 stm32f.c:152:mg_tcpip_driver_s PHY ID: 0x00 0x00
19     2 main.c:70:main                 MAC: 02:38:32:38:38:e7. Waiting for IP...
409    2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
7f1    2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
bd9    2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
fc1    2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
13a9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
1791   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
1b79   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
1f61   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
2349   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
2731   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
2b19   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
2f01   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
32e9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
36d1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
3ab9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
3ea1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
4289   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
4671   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
4a59   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
4e41   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
5229   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
5611   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
59f9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
5de1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
61c9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
65b1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
6999   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
6d81   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
7169   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
7551   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
7939   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
7d21   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
8109   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
84f1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
88d9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
8cc1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
90a9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
9491   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
9879   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
9c61   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
a049   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
a431   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
a819   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
ac01   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
afe9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
b3d1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
b7b9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
bba1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
bf89   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
c371   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
c759   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
cb41   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
cf29   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
d311   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
d6f9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
dae1   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
dec9   2 main.c:26:timer_fn             Ethernet: down, IP: 0.0.0.0, rx:0, tx:0, dr:0, er:0 RAM: 10828/40819
e2a9   3 stm32f.c:201:mg_tcpip_driver_s Link is 10M half-duplex
e2ae   1 net_builtin.c:202:onstatechang Link up
e2b2   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:38:e7
e2ba   2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:1, tx:1, dr:0, er:0 RAM: 10860/40787
e691   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:38:32:38:38:e7
e699   2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:1, tx:2, dr:0, er:0 RAM: 10860/40787
e6a2   3 net_builtin.c:281:tx_dhcp_requ DHCP req sent
e6a7   2 net_builtin.c:408:rx_dhcp_clie Lease: 6793 sec (6852)
e6ac   2 net_builtin.c:197:onstatechang READY, IP: 10.1.1.210
e6b2   2 net_builtin.c:198:onstatechang        GW: 10.1.1.1
e6b8   2 net_builtin.c:199:onstatechang       MAC: 02:38:32:38:38:e7
e6be   2 main.c:75:main                 Initialising application...
e6c4   3 net.c:202:mg_listen            1 0 http://0.0.0.0:8000
e6c9   3 net.c:202:mg_listen            2 0 http://0.0.0.0/
e6cf   3 net.c:202:mg_listen            3 0 https://0.0.0.0/
e6d4   2 main.c:79:main                 Starting event loop
e6d9   3 net.c:177:mg_connect           4 -1 udp://time.google.com:123
e6e0   3 net.c:177:mg_connect           5 -1 udp://8.8.8.8:53
e6e5   3 net_builtin.c:997:mg_connect_r 5 10.1.1.210:32768 -> 8.8.8.8:53
ea81   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.210, rx:4, tx:5, dr:0, er:0 RAM: 12060/39587
ee69   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.210, rx:5, tx:5, dr:0, er:0 RAM: 12060/39587
f251   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.210, rx:5, tx:5, dr:0, er:0 RAM: 12060/39587
f299   3 net.c:151:mg_close_conn        4 -1 closed
f639   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.210, rx:5, tx:5, dr:0, er:0 RAM: 12060/39587

Wonder if i'm fighting spanning tree (i have rstp) enabled on the HP ... Well no RSTP on the D-Link
It seems like it gets a link quicker from POR , than programming ....

Well ... I'll wait for my other boards (en route from Ali...)

@tellurium
Thank you for your support ....

And still strange that a NVIC Reset if no link , brings the link up immediately on next boot.

/Bingo

[tellurium]

It looks like it has no problem getting an IP when it senses the link

"Ethernet: down" - this means that the driver does not think there is a link, so it does not even try to send DHCP requests.

And, by the way, you've built with 64k RAM support, I can see here: " RAM: 10828/40819"
40k free RAM. By default, without CFLAGS_EXTRA, it is less than that.

[bingo600]

It looks like it has no problem getting an IP when it senses the link

"Ethernet: down" - this means that the driver does not think there is a link, so it does not even try to send DHCP requests.

Yepp , once it gets the ether-link it's quite fast to get the ip via dhcp.
But it's struggling a bit to obtain the link, i can see the switchport led is out ...

And, by the way, you've built with 64k RAM support, I can see here: " RAM: 10828/40819"
40k free RAM. By default, without CFLAGS_EXTRA, it is less than that.

Yep - I did your extras flag.

Here's my latest Makefile.
I added a linker map , and a linker flash/ram printout


The switchport strangeness is weird.
I have no issue getting a link/ip - If i use the same cable/port on the HP , on a Raspi3 or OrangePi-One , but they prob linkup on 100Mb

[tellurium]

Thank you!
Did you try to build a Mounriver example? I am curious, would it be able to sense the link, or have the same issue

[bingo600]

I don't have mounriver installed ...
Right now i just use : xpack-riscv-none-elf-gcc-13.2.0-2

I'm not always that keen on installing "strange IDE's"
But i have just downloaded it ...

I'm on linux (mint)
Seems like the DL is just the toolchain + OOCD

Well i do have Eclipse installed already ....

Maybe i'll consider



Any pointers to a "working" MounRiver example ?

[bingo600]

Well I just did try ddrown's iperf server

https://github.com/ddrown/ch32v307-lwip-example

Here i have an issue too..

Code: [Select]

Error:Wait phy linking timeout!
Please cheak MID.
Program has been blocked!

And after pressing "Board reset" , it works.

Code: [Select]

Enter main loop.
PLL3 is ready.
PHY_SR value:0004.
Full Duplex.
CH307_INIT_PHY ok
enable rng ok
This routine will use DHCP to dynamically assign IP addresses.
本例程将使用DHCP动态分配IP地址,如果不需要则在lwipopts.h中将LWIP_DHCP定义为0

lwip dhcp start success...

IP 10.1.1.211


Neat iperf test 

Code: [Select]

~/1-RiscV/gcc$ iperf -i 1 -c ch32v307
------------------------------------------------------------
Client connecting to ch32v307, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  1] local 10.1.1.182 port 54988 connected with 10.1.1.211 port 5001
[ ID] Interval       Transfer     Bandwidth
[  1] 0.0000-1.0000 sec  1.13 MBytes  9.44 Mbits/sec
[  1] 1.0000-2.0000 sec  1.12 MBytes  9.44 Mbits/sec
[  1] 2.0000-3.0000 sec  1.12 MBytes  9.44 Mbits/sec
[  1] 3.0000-4.0000 sec  1.12 MBytes  9.44 Mbits/sec
[  1] 4.0000-5.0000 sec   896 KBytes  7.34 Mbits/sec
[  1] 5.0000-6.0000 sec  1.12 MBytes  9.44 Mbits/sec
[  1] 6.0000-7.0000 sec  1.12 MBytes  9.44 Mbits/sec
[  1] 7.0000-8.0000 sec  1.12 MBytes  9.44 Mbits/sec
[  1] 8.0000-9.0000 sec  1.00 MBytes  8.39 Mbits/sec
[  1] 9.0000-10.0000 sec  1.00 MBytes  8.39 Mbits/sec
[  1] 0.0000-10.1062 sec  10.9 MBytes  9.03 Mbits/sec
:~/1-RiscV/gcc$


So it seems like i have a local issue somewhere

I think i'll get my other boards from ali soon , seems like they have cleared customs ...
Let's see if they have same issue.

/Bingo

[tellurium]

I think i'll get my other boards from ali soon , seems like they have cleared customs ...
Let's see if they have same issue.

Thank you, appreciate the effort!
Concerning the firmware functionality itself. Do you have a specific use case, where you might use the modbus functionality for some practical task?

[bingo600]

I think i'll get my other boards from ali soon , seems like they have cleared customs ...
Let's see if they have same issue.

Thank you, appreciate the effort!
Concerning the firmware functionality itself. Do you have a specific use case, where you might use the modbus functionality for some practical task?

No not really yet ...
I just liked the way the mongoose framework was presenting it self, "easy webpage" etc ...

But i do have a Solar Controller that speaks modbus, and was considering a "web status page" for that one.

I was thinking more in the way of Home Automation ...
Connect one of those cheap 4-chan relay boards, and make a webpage to turn on/off. Think mini "Tasmota" but for wired ethernet
Or Temp sensors etc ...
Maybe also control relay state via wget/curl, and read values via modbus and/or SNMP.
I like the way the APC master switches can be controlled via SNMP. Makes controlling soo easy from a linux server.

Note: 
I'm a hobbyist (w. a fulltime job) , so i might be "dreaming" a bit with the above ... 
I have never made any embeddd network programming or http page design.

/Bingo

[tellurium]

Great, thank you!
I am looking for a feedback from anyone who'd use that modbus firmware, regardless whether it is a hobby or a commercial project.
Those are not far apart anyways.

My idea behind this particular implementation of modbus firmware was to make it possible to relay modbus to MQTT:

1. Provide a UI to configure modbus endpoints: like, addresses, poll intervals, etc. That should be on the setting page, https://mongoose.ws/modbus-dashboard/#/settings
2. Provide an optional MQTT endpoint, also on the settings page. If that is configured, the result of every modbus poll will be relayed to MQTT. This can be used for home/building automation
3. The dashboard page, https://mongoose.ws/modbus-dashboard/#/, should just list configured devices (endpoints), and their status.
4. Optionally, a reverse MQTT path could be implemented. For example, by writing to a certain topic a certain message, one could write to a modbus endpoint. This way, this firmware could act as a two-way Modbus <-> MQTT gateway

That's what I have in mind, but that is something I just imagined. I'd like to have a feedback from someone who'd actually use that - or, similar functionality, before implementing it.

bingo600, that said, if you have some practical use case and you'd like it to be reflected in the UI - please let me know!

And I appreciate your time & attention so far.

[bingo600]

Got my new boards from ALI today

Here's the mongoose fw on the same type board , as used previously (with the Ether-Link issue)

Absolutely no issue ... with the new board

Code: [Select]

0      2 main.c:46:main                 Starting, CPU freq 144 MHz
5      2 main.c:51:main                 RAM/FLASH configuration: 64/256
c      2 main.c:55:main                 Heap size: 48032 bytes. RAM: used 1032, free 50823
14     3 stm32f.c:152:mg_tcpip_driver_s PHY ID: 0x00 0x00
19     2 main.c:70:main                 MAC: 02:50:37:7e:37:e5. Waiting for IP...
401    3 stm32f.c:201:mg_tcpip_driver_s Link is 10M half-duplex
406    1 net_builtin.c:202:onstatechang Link up
40a    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
412    2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:1, dr:0, er:0 RAM: 10860/40787
7e9    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
7f1    2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:2, dr:0, er:0 RAM: 10860/40787
bd1    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
bd9    2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:3, dr:0, er:0 RAM: 10860/40787
fb9    3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
fc1    2 main.c:26:timer_fn             Ethernet: up, IP: 0.0.0.0, rx:0, tx:4, dr:0, er:0 RAM: 10860/40787
13a1   3 net_builtin.c:302:tx_dhcp_disc DHCP discover sent. Our MAC: 02:50:37:7e:37:e5
13a8   3 net_builtin.c:281:tx_dhcp_requ DHCP req sent
13ad   2 net_builtin.c:408:rx_dhcp_clie Lease: 7132 sec (7137)
13b3   2 net_builtin.c:197:onstatechang READY, IP: 10.1.1.219
13b8   2 net_builtin.c:198:onstatechang        GW: 10.1.1.1
13be   2 net_builtin.c:199:onstatechang       MAC: 02:50:37:7e:37:e5
13c4   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.219, rx:2, tx:7, dr:0, er:0 RAM: 10860/40787
13ce   2 main.c:75:main                 Initialising application...
13d4   3 net.c:202:mg_listen            1 0 http://0.0.0.0:8000
13da   3 net.c:202:mg_listen            2 0 http://0.0.0.0/
13df   3 net.c:202:mg_listen            3 0 https://0.0.0.0/
13e5   2 main.c:79:main                 Starting event loop
13ea   3 net.c:177:mg_connect           4 -1 udp://time.google.com:123
13f0   3 net.c:177:mg_connect           5 -1 udp://8.8.8.8:53
13f6   3 net_builtin.c:997:mg_connect_r 5 10.1.1.219:32768 -> 8.8.8.8:53
1791   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.219, rx:3, tx:8, dr:0, er:0 RAM: 12060/39587
1b79   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.219, rx:3, tx:8, dr:0, er:0 RAM: 12060/39587
1f61   2 main.c:26:timer_fn             Ethernet: ready, IP: 10.1.1.219, rx:3, tx:8, dr:0, er:0 RAM: 12060/39587
1fa9   3 net.c:151:mg_close_conn        4 -1 closed


So my first board is strange .... 
Only difference is that i have soldered the dual header rows on the first board.
But i have checked the soldering , and even cleaned it with a toothbrush and IPA.


I also got some of the boards you tested on first port .....
But it seems like i'd need to do DFU load on that one ... (Well it doesn't have the easy 10-pin header the other board has)
Haven't tried DFU yet , but i think there might be a "Boot" button ...

Edit:
Well DFU was just as on a STM32F4   - Press RST + Boot , then release RST , and then Boot.
I used the wchisp for programming that one ...

No issues ...

/Bingo

[bingo600]

I just had a headscratcher   

I got a few of these boards
https://www.aliexpress.com/item/1005004350410929.html

And tried to load the webapp.
This time putting the board in DFU mode , and use wchisp for programming via an USB-C cable.
One board was success , two other boards failed in verify.

I tried to switch to another USB cable ... Same result. 

After digging a bit i found out the boards came from the factory with flash protection active 

Below are my notes for disabling flash protection via wchisp.

Enter DFU mode (like STM32F4)

Press Reset + BOOT0
Release Reset
Release Boot0




***********  WCHISP ********

Commands
-------------------

> wchisp flash ./path/to/firmware.{bin,hex,elf}

> wchisp config info

> wchisp config reset

******************************

Info Unprotected
$ wchisp info
14:26:26 [INFO] Chip: CH32V307VCT6[0x7017] (Code Flash: 256KiB)
14:26:26 [INFO] Chip UID: FD-47-89-26-3B-38-C1-A6
14:26:26 [INFO] BTVER(bootloader ver): 02.90
14:26:26 [INFO] Code Flash protected: false  <<<---------*** UNPROTECTED
14:26:26 [INFO] Current config registers: a55aff0000ff00ffffffffff00020900fd4789263b38c1a6
RDPR_USER: 0x00FF5AA5
  [7:0]   RDPR 0xA5 (0b10100101)
    `- Unprotected         <<<---------*** UNPROTECTED
  [16:16] IWDG_SW 0x1 (0b1)
    `- IWDG enabled by the software, and disabled by hardware
  [17:17] STOP_RST 0x1 (0b1)
    `- Disable
  [18:18] STANDBY_RST 0x1 (0b1)
    `- Disable, entering standby-mode without RST
  [23:22] SRAM_CODE_MODE 0x3 (0b11)
    `- CODE-228KB + RAM-32KB   <<<-------****** Flash/Ram mode
DATA: 0xFF00FF00
  [7:0]   DATA0 0x0 (0b0)
  [23:16] DATA1 0x0 (0b0)
WRP: 0xFFFFFFFF
  `- Unprotected

*********************

Info Protected
$ wchisp info
14:21:38 [WARN] WRP register: bfffffff
14:21:38 [INFO] Chip: CH32V307VCT6[0x7017] (Code Flash: 256KiB)
14:21:38 [INFO] Chip UID: 3F-49-89-26-3B-38-03-A8
14:21:38 [INFO] BTVER(bootloader ver): 02.90
14:21:38 [INFO] Code Flash protected: true  <<<---------*** PROTECTED
14:21:38 [INFO] Current config registers: ff001fe000ff00ffbfffffff000209003f4989263b3803a8
RDPR_USER: 0xE01F00FF
  [7:0]   RDPR 0xFF (0b11111111)
    `- Protected    <<<---------*** PROTECTED
  [16:16] IWDG_SW 0x1 (0b1)
    `- IWDG enabled by the software, and disabled by hardware
  [17:17] STOP_RST 0x1 (0b1)
    `- Disable
  [18:18] STANDBY_RST 0x1 (0b1)
    `- Disable, entering standby-mode without RST
  [23:22] SRAM_CODE_MODE 0x0 (0b0)
    `- CODE-192KB + RAM-128KB   <<<-------****** Flash/Ram mode
DATA: 0xFF00FF00
  [7:0]   DATA0 0x0 (0b0)
  [23:16] DATA1 0x0 (0b0)
WRP: 0xFFFFFFBF
  `- Some 4K sections are protected   <<<---------*** PROTECTED


*********************

Config Reset (If info shows protected)

wchisp config reset
** Must power reset device after config reset ... "Flash unprotect" (like on stm)

*********************

Note that the config reset will set the MCU for default 32K Ram / 288K Flash.
And that it seems like wchisp doesn't have code for setting the Ram/Flash config .... yet.


If you're using wchisp , there is a way to get mongoose to set the (preferred) 64K Ram/ 256K Flash for you ... Thnx Tellurium 

1:
Uncomment this line in main.c , to have mogoose set the config.


2:
Do a : make clean all   (It will build for 32K)

3:
Upload that ...
Now the chip should be set for 64K Ram.

4:
Now build for 64K Ram
make CFLAGS_EXTRA='-Wl,--defsym -Wl,RAM_64K=1' clean all

5:
Upload that ....


wchisp won't touch/change the Ram/Flash config, unless told to reset config.
So you could "recomment" the line you uncommented in main.c. If you prefer mongoose not to alter the Ram/Flash config.

 
/Bingo

[S. Petrukhin]

If it's not difficult, please tell me how it works?
Does ch32v307 issue a Modbus exchange web page on an http request?

[tellurium]

If it's not difficult, please tell me how it works?
Does ch32v307 issue a Modbus exchange web page on an http request?

Correct. This is how it works:

1. A button click on the Web UI page triggers a REST API call, /api/modbus/exec:
https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L262-L263

2. Which in turn creates a modbus TCP connection to the target device:
https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L187-L188

The original HTTP REST request waits, but starts a software timer: https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L192-L193

3. The modbus connection (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L144C40-L145) sends a request to a target device (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L147-L181)
and when it receives a response (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L104-L107),
it finds an original REST request (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L109-L111) and notifies it about the modbus response. An original REST request then sends a reponse to the Web UI (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L285-L292)

4. In case if modbus request times out, the original REST connection returns failure (https://github.com/cesanta/mongoose/blob/c8d45c9ff1b3042919d19ba823415d35ce1b0fbc/examples/modbus-dashboard/net.c#L281-L283)

[S. Petrukhin]

Correct. This is how it works:

Thanks for the detailed answer!
I have never used REST technology. 

That is, do you have your own application that exchanges with MK?

I'm asking because my devices have a WEB interface targeted for using the browser.
I did not find in JS the possibility of a direct binary request for Modbus exchange and made Modbus/HTTP.
The browser sends get requests, usint fetch request.
For example, /read?bank=4&startreg=10&count=2 and receives responses in the body in the form of values=34,56 or error=4

[tellurium]

I did not find in JS the possibility of a direct binary request for Modbus exchange and made Modbus/HTTP.
The browser sends get requests, usint fetch request.
For example, /read?bank=4&startreg=10&count=2 and receives responses in the body in the form of values=34,56 or error=4

JS inside the browser is limited only to HTTP and Websocket protocols. It cannot create arbitrary TCP/UDP connections.
Therefore, the Web UI talks (via HTTP REST) to a device, and a device in turn creates arbitrary connections. In our case, it is Modbus.

REST means "representational state transfer", but basically, if you think that "HTTP", "REST", or "Ajax" is the same - you won't be mistaken. It's the same stuff. That is, making HTTP requests to get some data.

[S. Petrukhin]

Thanks! I had a doubt that I was behind the times and missed the opportunities of JS.