OpenOCD support for nuvoton M0516LBN CPU

[Paweł Si]

I'm currently writing a patch for OpenOCD (upgrade for the mini51.c driver):

http://openocd.sourceforge.net/

which should allow to flash (maybe also debug) the nuvoton M051 CPUs

under Linux.

(I'm not sure what I'm actually doing ;) ,the project is to complex for me but)

flashing seems to work.

If someone is interested in downloading the original firmware

from a charger (with the security lock turned on),

and has a OpenOCD supported SWD adapter,

please let me know.

Maybe it's possible with OpenOCD (or maybe not).

Best Regards,

Paweł

[sasam]

I saw that you submitted patch to OpenOCD http://openocd.zylin.com/#/c/2426/
Did you successfully erase flash reset config registers?

Last night i decided to setup cheali-charger development environment on Linux. I follow instructions "Building from Source" from your test branch. I have few problems but finlay I successfully build ARM version. I will try do describe full procedure.

I decided to tray with VMware_Player on my desktop PC with XP windows.

1. download VMvare Lubuntu 14.04 image http://www.trendsigma.net/vmware/lubuntu1404t.html

2. upgrade VMware_Player to version 6.0.4 ( https://my.vmware.com/web/vmware/free#desktop_end_user_computing/vmware_player/6_0|PLAYER-604|product_downloads )

3. follow instructions form tutorial https://github.com/stawel/cheali-charger/blob/test/docs/building.md#nuvoton-m0517---linux

user@~$ sudo apt-get install git cmake  gcc-arm-none-eabi
user@~$ git clone https://github.com/stawel/cheali-charger.git
user@~$ cd cheali-charger
user@~/cheali-charger$ ./bootstrap-arm
user@~/cheali-charger$ make

After that I had first problem. I got error that avr compiler is not found. In the first moment i did not understand what is going on because I wont to compile with gcc-arm not gcc-avr. After some time I understand that CMakeLists.txt it writen with assumption that avr compiler is alredy instaled. Because I am not familiar with cmake I decided to instal avr compiler and try again.

4. instaled gcc-avr compiler https://github.com/stawel/cheali-charger/blob/test/docs/building.md#atmega32---linux

user@~$ sudo apt-get install cmake avrdude avr-libc gcc-avr git
user@~/cheali-charger$ ./bootstrap-arm user@~/cheali-charger$ make

After that I had second problem. It still not compile because some header files are missing. 
Package gcc-arm-none-eabi from standard Ubuntu repository is not OK or probably it need another packages with headers.
Solution for this problem i found here: https://github.com/stawel/cheali-charger/blob/master/arm-compiler.cmake#L3

with reference to https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded

5. follow instructions from here: https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded

!!! If you are using Ubuntu 14.04 and later, please be careful because there are packages with same name but produced by Debian and inherited by Ubuntu. Simply follow the above 3 steps, you may end up with gcc-arm-none-eabi from Ubuntu. So to install gcc-arm-none-eabi from ARM, steps are:
1). sudo apt-get remove binutils-arm-none-eabi gcc-arm-none-eabi

2). sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
3). sudo apt-get update
4). sudo apt-get install gcc-arm-none-eabi=4.9.3.2014q4-0trusty12
    or
    sudo apt-get install gcc-arm-none-eabi=4.9.3.2014q4-0utopic12

When finished with this removal/installation I finally compiled arm version on Linux.
I note difference in code size when compared with CooCox CoIDE version. For CooCox build i am using gcc-arm-none-eabi_4.8 2014q2 so i decided to try with same version on linux.

6. install gcc-arm-none-eabi_4.8 2014q2
On the same site i found package for gcc_arm version 4-8-2014q2

download this file:
     https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded/+files/gcc-arm-none-eabi_4-8-2014q2-0saucy9_i386.deb

remove version 4.9.3.2014q4-0trusty12

user@~$ sudo apt-get remove gcc-arm-none-eabi

install gcc-arm-none-eabi_4-8-2014q2-0saucy9_i386.deb by clik on this file from file manager.

[100%] Built target cheali-charger-imaxB6-clone_0.99-20141213_nuvoton-M0517
code-size for different compiler version:
gcc-version    text       data        bss        dec        hex
4.9.3.2014q4  32420       1120       3916      37456       9250
4-8-2014q2-0  31964       1120       3916      37000       9088


TODO:

• It seems to me that on site http://gnuarmeclipse.livius.net/blog/toolchain-install/ we can find all information necessary to build Eclipse based development environment for ARM. Probably I will tray to install something similar on my VMware LUbuntu image. Does somebody try to build GNU ARM Eclipse according this site?

• Try to build OpenOCD for ST-linkV2 with Pawel patch for M051x. Pawel do you have any suggestions regarding this build?
  

Best Regards,
Saša

[Paweł Si]

2014-12-14 2:26 GMT+01:00 sasam <sasa.mi...@gmail.com>:

I saw that you submitted patch to OpenOCD http://openocd.zylin.com/#/c/2426/
Did you successfully erase flash reset config registers?

 

Yes, even without connecting the RESET pin on my STM32F4Discovery board,

unfortunately I was not able to "hack" into the cpu with "security lock" turned on :/

 

Last night i decided to setup cheali-charger development environment on Linux.

 

Great!

 

I follow instructions "Building from Source" from your test branch.

 

It's a new README, still under construction (is a nightmare for me :/)

 

... CMakeLists.txt it writen with assumption that avr compiler is alredy instaled.

 

Fixed

 

After that I had second problem. It still not compile because some header files are missing. 
Package gcc-arm-none-eabi from standard Ubuntu repository is not OK or probably it need another packages with headers.

added to:  docs/building.md

gcc-version    text       data        bss        dec        hex
4.9.3.2014q4  32420       1120       3916      37456       9250
4-8-2014q2-0  31964       1120       3916      37000       9088

interesting 

 

 

TODO:

• It seems to me that on site http://gnuarmeclipse.livius.net/blog/toolchain-install/ we can find all information necessary to build Eclipse based development environment for ARM. Probably I will tray to install something similar on my VMware LUbuntu image. Does somebody try to build GNU ARM Eclipse according this site?

Not according to this site, but I'm using eclipse, you need to:

1 .run cmake with the "./bootstrap-arm" command

2. in eclipse: "File"->"Import"->"General"->"Existing Project into Workspace"

3. set: "Select root directory" to your cheali-charger directory, and "Finish"

if you need debugging (patched OpenOCD needed):

4. install: http://gnuarmeclipse.livius.net/blog/openocd-debugging/

5. additionally to "OpenOCD plug-in usage":

   -  in "Debugger"->"OpenOCD setup"->"other options" set to: "-f interface/stlink-v2.cfg -f target/m051.cfg"

   -  in "Debugger"->"GDB client setup"->"executable:" set to "/usr/bin/arm-none-eabi-gdb"

• Try to build OpenOCD for ST-linkV2 with Pawel patch for M051x. Pawel do you have any suggestions regarding this build?

I've made a branch on github with the patch: https://github.com/stawel/openocd

 

 hmm... I don't remember all dependencies :/ probably it was:

$ sudo apt-get install build-essential autoconf automake libtool libusb-1.0-0-dev

$ cd openocd

openocd$ ./bootstrap 

openocd$ ./configure

after that you should see:

..

ST-Link JTAG Programmer                 yes (auto)

openocd$ make

openocd$ sudo make install

running openocd:

openocd$ sudo cp contrib/99-openocd.rules to /etc/udev/rules.d/

openocd$ openocd -f interface/stlink-v2.cfg -f target/m051.cfg

if everything is ok, you can connect to openocd through telnet:

(run in another console)

$ telnet localhost 4444

useful help commands:

> flash

> help flash

> mini51

> help mini51

> target

> help target

> m051.cpu

> help m051.cpu

useful commands:

> halt

> resume

> flash banks

(chip erase)

> halt

> mini51 chip_erase

(read eprom using isp, address = 0x300000 - config)

> halt

> mini51 read_isp 0x300000

(write eprom using isp, address = 0x300000, data 0xFFFFFFFD - "security lock" on) 

> halt

>mini51 write_isp 0x300000 0xFFFFFFFD

(display all registers)

> halt

> reg

(read RAM)

> halt

> m051.cpu mdw 0x20000000 100

Best Regards,

Paweł

[sasam]

I've made a branch on github with the patch: https://github.com/stawel/openocd

 

 hmm... I don't remember all dependencies :/ probably it was:

$ sudo apt-get install build-essential autoconf automake libtool libusb-1.0-0-dev

Also I need pkg-config

$ cd openocd

openocd$ ./bootstrap 

openocd$ ./configure

after that you should see:

..

ST-Link JTAG Programmer                 yes (auto)

openocd$ make

openocd$ sudo make install

running openocd:

openocd$ sudo cp contrib/99-openocd.rules to /etc/udev/rules.d/

openocd$ openocd -f interface/stlink-v2.cfg -f target/m051.cfg

if everything is ok, you can connect to openocd through telnet:

(run in another console)

$ telnet localhost 4444

I compiled openocd. When connect with telnet it seems that everything is fine but when start progStLink.sh it start but newer finish. Maybe problem with VMware or something else. Now it is to late to investigate and try manually flash firmware.
Before tray to flas firmware I play with some commands you mention.
Any suggestions?

user@ubuntu:~/cheali-charger/src/hardware/nuvoton-M0517/targets/imaxB6-clone$ ./progStLink.sh
+ PROGRAMMER=interface/stlink-v2.cfg
+ TARGET=target/m051.cfg
++ ls cheali-charger-imaxB6-clone_0.99-20141215_nuvoton-M0517.hex
+ HEX=cheali-charger-imaxB6-clone_0.99-20141215_nuvoton-M0517.hex
+ echo HEX=cheali-charger-imaxB6-clone_0.99-20141215_nuvoton-M0517.hex
HEX=cheali-charger-imaxB6-clone_0.99-20141215_nuvoton-M0517.hex
+ '[' '' '!=' --no-backup ']'
++ date +%F_%T
+ NOW=2014-12-15_03:40:48
+ DIR=backup/2014-12-15_03:40:48
+ echo 'creating buckup: backup/2014-12-15_03:40:48'
creating buckup: backup/2014-12-15_03:40:48
+ mkdir -p backup/2014-12-15_03:40:48
+ cd backup/2014-12-15_03:40:48
+ openocd -f interface/stlink-v2.cfg -f target/m051.cfg -c 'init; dump_image aprom.bin 0x0 0x10000; dump_image flash_data.bin 0x1f000 0x1000; shutdown '
Open On-Chip Debugger 0.9.0-dev-00211-g3da9300 (2014-12-15-02:54)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v19 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.532372
Info : m051.cpu: hardware has 4 breakpoints, 2 watchpoints
dumped 65536 bytes in 3.952942s (16.190 KiB/s)
dumped 4096 bytes in 0.246728s (16.212 KiB/s)
shutdown command invoked
+ openocd -f interface/stlink-v2.cfg -f target/m051.cfg -c 'init; dump_image ldrom.bin  0x100000 0x1000; shutdown '
Open On-Chip Debugger 0.9.0-dev-00211-g3da9300 (2014-12-15-02:54)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v19 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.521363
Info : m051.cpu: hardware has 4 breakpoints, 2 watchpoints
in procedure 'dump_image'
+ openocd -f interface/stlink-v2.cfg -f target/m051.cfg -c 'init; dump_image config.bin 0x300000 0x1000; shutdown '
Open On-Chip Debugger 0.9.0-dev-00211-g3da9300 (2014-12-15-02:54)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v19 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.529227
Info : m051.cpu: hardware has 4 breakpoints, 2 watchpoints
in procedure 'dump_image'
+ cd -
/home/user/cheali-charger/src/hardware/nuvoton-M0517/targets/imaxB6-clone
+ openocd -f interface/stlink-v2.cfg -f target/m051.cfg -c 'program cheali-charger-imaxB6-clone_0.99-20141215_nuvoton-M0517.hex verify reset'
Open On-Chip Debugger 0.9.0-dev-00211-g3da9300 (2014-12-15-02:54)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v19 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.529227
Info : m051.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000010b4 msp: 0x20000fc8
** Programming Started **
auto erase enabled
Info : device id = 0x10005a00
Info : device name = M0516LBN
Info : bank base = 0x00000000, size = 0x00010000

[Paweł Si]

2014-12-15 3:52 GMT+01:00 sasam <sasa.mi...@gmail.com>:

I compiled openocd. When connect with telnet it seems that everything is fine but when start progStLink.sh it start but newer finish. Maybe problem with VMware or something else. Now it is to late to investigate and try manually flash firmware.
Before tray to flas firmware I play with some commands you mention.
Any suggestions?

try to  entirely erase the chip:

$ openocd -f interface/stlink-v2.cfg  -f target/m051.cfg -c "init ; halt ; mini51 chip_erase; exit"

[sasam]

There is no difference, I have the same situation as before :(
Yesterday I tray to erase from terminal connected to openocd, it seems to work and I did not try from command line. Yesterday I didn't try to lock with Bu-Link but now i set protection bit with Bu-Link and erased from command line with openocd.

here is results:

$ openocd -f interface/stlink-v2.cfg  -f target/m051.cfg -c "init ; halt ; mini51 chip_erase; exit"

Open On-Chip Debugger 0.9.0-dev-00211-g3da9300 (2014-12-15-02:54)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v19 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2

Info : Target voltage: 3.513725

Info : m051.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted

target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0xfffffffe msp: 0x20000f70
in procedure 'exit'

When start ./progStLink.sh resalt is the same as before
...

adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v19 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2

Info : Target voltage: 3.512157

Info : m051.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread

xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc

** Programming Started **
auto erase enabled
Info : device id = 0x10005a00
Info : device name = M0516LBN
Info : bank base = 0x00000000, size = 0x00010000

-------

in backup dir I found this files:
-rw-rw-r-- 1 user user 65536 Dec 15 17:36 aprom.bin
-rw-rw-r-- 1 user user     0 Dec 15 17:36 config.bin
-rw-rw-r-- 1 user user  4096 Dec 15 17:36 flash_data.bin
-rw-rw-r-- 1 user user     0 Dec 15 17:36 ldrom.bin

It sems that erase command work:

$ for i in *.bin
> do
> echo $i
> od -x $i
> echo "============="
> done
aprom.bin
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0200000
=============
config.bin
0000000
=============
flash_data.bin
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000
=============
ldrom.bin
0000000
=============

For second run of ./progStLink.sh
aprom.bin is not empty

[Paweł Si]

2014-12-15 17:53 GMT+01:00 sasam <sasa.mi...@gmail.com>:

Dana ponedjeljak, 15. prosinca 2014. 13:48:07 UTC+1, korisnik cheali-charger napisao je:

...

adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v19 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.512157
Info : m051.cpu: hardware has 4 breakpoints, 2 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
auto erase enabled
Info : device id = 0x10005a00
Info : device name = M0516LBN
Info : bank base = 0x00000000, size = 0x00010000

looks like some write problems,

I had something similar, I've changed the Vdd to 5V and

suddenly everything began to work.

[sasam]

looks like some write problems,

I had something similar, I've changed the Vdd to 5V and

suddenly everything began to work.

I don't know how to change target voltage to 5V. On my ST-LInk V2 I have 3.3V and 5V pin. OpenOCD Target voltage info does not change when I connect 3.3V ov 5V pin.
With CooCox (CoIDE) and Keil under XP window I can flash without problem (same wiring).

[sasam]

CooCox CoIDE successfully flash my M0517 over ST-Link V2. Vcc voltage can be connect to 5V or 3.3V. Flashing work, but LCD display is not visible when Vcc is connected on 3.3V so I usually Vcc connect to 5V pin of my ST-Link V2.

[sasam]

Dana nedjelja, 14. prosinca 2014. 16:02:26 UTC+1, korisnik cheali-charger napisao je:

gcc-version    text       data        bss        dec        hex
4.9.3.2014q4  32420       1120       3916      37456       9250
4-8-2014q2-0  31964       1120       3916      37000       9088

interesting 

 

Probably it is known problem in 4.9.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535

[Paweł Si]

2014-12-16 1:21 GMT+01:00 sasam <sasa.mi...@gmail.com>:

CooCox CoIDE successfully flash my M0517 over ST-Link V2.

I had write problems also in CoIDE and nuvoton ICP tool.

 

Vcc voltage can be connect to 5V or 3.3V. Flashing work, but LCD display is not visible when Vcc is connected on 3.3V so I usually Vcc connect to 5V pin of my ST-Link V2.

I have no idea what's going on in OpenOCD, maybe it's the VMware, but on the other hand,

chip erase and read works so it's probably not that.

you could try to reproduce the "program" command by hand in telnet,

a simplified version would look like this (write only 4 bytes):

> halt

> flash probe 0

> mini51 read_isp 0x0

0x0000000: 0xffffffff

> mini51 write_isp 0x0 0x12345678

> mini51 read_isp 0x0

0x0000000: 0x12345678

(check if erase works)

>flash erase_sector 0 0 1

> mini51 read_isp 0x0

0x0000000: 0xffffffff

hmm... also the ./progStLink.sh takes a while (~1min) maybe you are terminating it too early?

[sasam]

I have no idea what's going on in OpenOCD, maybe it's the VMware, but on the other hand,

chip erase and read works so it's probably not that.

Yes I doubt it can be VMware related problem. On this PC i have one real Linux partition but with old Ubuntu. On this partition i have development env with ARM croscompiler for XCSoar for my Kobo mini. Probably I will try to bild openocd to see what will happen.
 

you could try to reproduce the "program" command by hand in telnet,

a simplified version would look like this (write only 4 bytes):

> halt

> flash probe 0

> mini51 read_isp 0x0

0x0000000: 0xffffffff

> mini51 write_isp 0x0 0x12345678

> mini51 read_isp 0x0

0x0000000: 0x12345678

(check if erase works)

>flash erase_sector 0 0 1

> mini51 read_isp 0x0

0x0000000: 0xffffffff

hmm... also the ./progStLink.sh takes a while (~1min) maybe you are terminating it too early?

Last night i tried something similar (started openocd & connected with telnet than tray to read, erase, flash, read, ...). My conclusion is that openocd work but very very slowly when write to flash. Also put openocd in debug mode 3, and then write to flash. When in this mode openocd print all info on console. I think it last more than 5min before I kill this process. In this test I try to flash 64K file. Interesting is that for read operation it need lees then 2s to finish, but for write it is never-ending story.

[sasam]

> halt

> flash probe 0

> mini51 read_isp 0x0

0x0000000: 0xffffffff

> mini51 write_isp 0x0 0x12345678

> mini51 read_isp 0x0

0x0000000: 0x12345678

(check if erase works)

>flash erase_sector 0 0 1

> mini51 read_isp 0x0

0x0000000: 0xffffffff

Something is wrong with flash write.
> halt
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x21000003 pc: 0x000008cc msp: 0x20000fe0
> flash probe 0                  
device id = 0x10005a00
device name = M0516LBN

bank base = 0x00000000, size = 0x00010000

flash 'mini51' found at 0x00000000
> mini51 read_isp 0x0           
0x00000000: 0x00200000
> mini51 write_isp 0x0 0x12345678
0x00000000: 0x12345678
> mini51 read_isp 0x0           
0x00000000: 0x00200000

> flash erase_sector 0 0 1      

erased sectors 0 through 1 on flash bank 0 in 1.042476s
> mini51 read_isp 0x0    
0x00000000: 0xffffffff

console display with debug_level 3:

Debug: 299 2079303 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_mini51 write_isp 0x0 0x12345678
Debug: 300 2079303 command.c:145 script_debug(): command - ocd_mini51 ocd_mini51 write_isp 0x0 0x12345678
Debug: 302 2079311 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000059
Debug: 303 2079311 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 304 2079326 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000016
Debug: 305 2079326 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 306 2079342 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000088
Debug: 307 2079342 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 308 2079358 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 309 2079373 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Debug: 310 2079373 target.c:2156 target_write_u32(): address: 0x5000c000, value: 0x00000039
Debug: 311 2079373 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c000 4 1
Debug: 312 2079389 target.c:2156 target_write_u32(): address: 0x5000c008, value: 0x12345678
Debug: 313 2079389 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c008 4 1
Debug: 314 2079405 target.c:2156 target_write_u32(): address: 0x5000c004, value: 0x00000000
Debug: 315 2079405 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c004 4 1
Debug: 316 2079420 target.c:2156 target_write_u32(): address: 0x5000c00c, value: 0x00000021
Debug: 317 2079420 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c00c 4 1
Debug: 318 2079436 target.c:2156 target_write_u32(): address: 0x5000c010, value: 0x00000001
Debug: 319 2079436 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c010 4 1
Debug: 320 2079452 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c010 4 1
Debug: 321 2079467 target.c:2068 target_read_u32(): address: 0x5000c010, value: 0x00000000
Debug: 322 2079467 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 323 2079483 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Info : 324 2079483 mini51.c:514 mini51_handle_write_isp_command(): 0x00000000: 0x12345678
Debug: 325 2088445 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_mini51 read_isp 0x0
Debug: 326 2088445 command.c:145 script_debug(): command - ocd_mini51 ocd_mini51 read_isp 0x0
Debug: 328 2088452 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000059
Debug: 329 2088452 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 330 2088467 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000016
Debug: 331 2088467 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 332 2088483 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000088
Debug: 333 2088483 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 334 2088499 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 335 2088514 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Debug: 336 2088514 target.c:2156 target_write_u32(): address: 0x5000c000, value: 0x00000039
Debug: 337 2088514 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c000 4 1
Debug: 338 2088530 target.c:2156 target_write_u32(): address: 0x5000c004, value: 0x00000000
Debug: 339 2088530 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c004 4 1
Debug: 340 2088545 target.c:2156 target_write_u32(): address: 0x5000c00c, value: 0x00000000
Debug: 341 2088545 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c00c 4 1
Debug: 342 2088561 target.c:2156 target_write_u32(): address: 0x5000c010, value: 0x00000001
Debug: 343 2088561 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c010 4 1
Debug: 344 2088577 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c010 4 1
Debug: 345 2088592 target.c:2068 target_read_u32(): address: 0x5000c010, value: 0x00000000
Debug: 346 2088592 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 347 2088608 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Debug: 348 2088608 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c008 4 1
Debug: 349 2088624 target.c:2068 target_read_u32(): address: 0x5000c008, value: 0x00200000
Info : 350 2088624 mini51.c:492 mini51_handle_read_isp_command(): 0x00000000: 0x00200000


 

[sasam]

Today I compile cheali-charger & openOCD on real Ubuntu Linux 14.04. Unfortunately I have identical behaviour as on LUbuntu on VMware under XP.

Could you try with your programer/debugger:
> debug_level 3                        
debug_level: 3
> mini51 read_isp 0x0
0x00000000: 0x00000670

> mini51 write_isp 0x0 0x12345678      
0x00000000: 0x12345678
> mini51 read_isp 0x0           

0x00000000: 0x00000670

and see what you have on console display
this is display from my console:
Debug: 3720 2018559 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_debug_level 3
Debug: 3721 2018559 command.c:145 script_debug(): command - debug_level ocd_debug_level 3
User : 3723 2018561 command.c:546 command_print(): debug_level: 3
Debug: 3724 2091263 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_mini51 read_isp 0x0
Debug: 3725 2091263 command.c:145 script_debug(): command - ocd_mini51 ocd_mini51 read_isp 0x0
Debug: 3727 2091266 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000059
Debug: 3728 2091266 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 3729 2091269 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000016
Debug: 3730 2091270 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 3731 2091273 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000088
Debug: 3732 2091274 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 3733 2091277 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 3734 2091281 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Debug: 3735 2091282 target.c:2156 target_write_u32(): address: 0x5000c000, value: 0x00000039
Debug: 3736 2091282 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c000 4 1
Debug: 3737 2091285 target.c:2156 target_write_u32(): address: 0x5000c004, value: 0x00000000
Debug: 3738 2091286 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c004 4 1
Debug: 3739 2091289 target.c:2156 target_write_u32(): address: 0x5000c00c, value: 0x00000000
Debug: 3740 2091290 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c00c 4 1
Debug: 3741 2091294 target.c:2156 target_write_u32(): address: 0x5000c010, value: 0x00000001
Debug: 3742 2091294 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c010 4 1
Debug: 3743 2091298 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c010 4 1
Debug: 3744 2091301 target.c:2068 target_read_u32(): address: 0x5000c010, value: 0x00000000
Debug: 3745 2091302 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 3746 2091305 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Debug: 3747 2091306 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c008 4 1
Debug: 3748 2091309 target.c:2068 target_read_u32(): address: 0x5000c008, value: 0x00000670
Info : 3749 2091310 mini51.c:492 mini51_handle_read_isp_command(): 0x00000000: 0x00000670
Debug: 3750 2102151 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_mini51 write_isp 0x0 0x12345678
Debug: 3751 2102151 command.c:145 script_debug(): command - ocd_mini51 ocd_mini51 write_isp 0x0 0x12345678
Debug: 3753 2102154 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000059
Debug: 3754 2102154 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 3755 2102157 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000016
Debug: 3756 2102158 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 3757 2102161 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000088
Debug: 3758 2102162 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 3759 2102166 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 3760 2102170 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Debug: 3761 2102170 target.c:2156 target_write_u32(): address: 0x5000c000, value: 0x00000039
Debug: 3762 2102170 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c000 4 1
Debug: 3763 2102173 target.c:2156 target_write_u32(): address: 0x5000c008, value: 0x12345678
Debug: 3764 2102174 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c008 4 1
Debug: 3765 2102177 target.c:2156 target_write_u32(): address: 0x5000c004, value: 0x00000000
Debug: 3766 2102178 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c004 4 1
Debug: 3767 2102182 target.c:2156 target_write_u32(): address: 0x5000c00c, value: 0x00000021
Debug: 3768 2102182 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c00c 4 1
Debug: 3769 2102186 target.c:2156 target_write_u32(): address: 0x5000c010, value: 0x00000001
Debug: 3770 2102186 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c010 4 1
Debug: 3771 2102190 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c010 4 1
Debug: 3772 2102193 target.c:2068 target_read_u32(): address: 0x5000c010, value: 0x00000000
Debug: 3773 2102194 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 3774 2102197 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Info : 3775 2102198 mini51.c:514 mini51_handle_write_isp_command(): 0x00000000: 0x12345678
Debug: 3776 2105703 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_mini51 read_isp 0x0
Debug: 3777 2105703 command.c:145 script_debug(): command - ocd_mini51 ocd_mini51 read_isp 0x0
Debug: 3779 2105706 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000059
Debug: 3780 2105706 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 3781 2105709 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000016
Debug: 3782 2105710 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 3783 2105713 target.c:2156 target_write_u32(): address: 0x50000100, value: 0x00000088
Debug: 3784 2105714 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x50000100 4 1
Debug: 3785 2105718 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 3786 2105722 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Debug: 3787 2105722 target.c:2156 target_write_u32(): address: 0x5000c000, value: 0x00000039
Debug: 3788 2105722 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c000 4 1
Debug: 3789 2105726 target.c:2156 target_write_u32(): address: 0x5000c004, value: 0x00000000
Debug: 3790 2105726 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c004 4 1
Debug: 3791 2105729 target.c:2156 target_write_u32(): address: 0x5000c00c, value: 0x00000000
Debug: 3792 2105730 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c00c 4 1
Debug: 3793 2105734 target.c:2156 target_write_u32(): address: 0x5000c010, value: 0x00000001
Debug: 3794 2105734 hla_target.c:780 adapter_write_memory(): adapter_write_memory 0x5000c010 4 1
Debug: 3795 2105738 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c010 4 1
Debug: 3796 2105741 target.c:2068 target_read_u32(): address: 0x5000c010, value: 0x00000000
Debug: 3797 2105742 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c000 4 1
Debug: 3798 2105745 target.c:2068 target_read_u32(): address: 0x5000c000, value: 0x00000039
Debug: 3799 2105746 hla_target.c:766 adapter_read_memory(): adapter_read_memory 0x5000c008 4 1
Debug: 3800 2105749 target.c:2068 target_read_u32(): address: 0x5000c008, value: 0x00000670
Info : 3801 2105750 mini51.c:492 mini51_handle_read_isp_command(): 0x00000000: 0x00000670

[Paweł Si]

2014-12-20 2:04 GMT+01:00 sasam <sasa.mi...@gmail.com>:

Today I compile cheali-charger & openOCD on real Ubuntu Linux 14.04. Unfortunately I have identical behaviour as on LUbuntu on VMware under XP.

Could you try with your programer/debugger:
> debug_level 3                        
debug_level: 3
> mini51 read_isp 0x0
0x00000000: 0x00000670
> mini51 write_isp 0x0 0x12345678      
0x00000000: 0x12345678
> mini51 read_isp 0x0           
0x00000000: 0x00000670

it works as it should, we have here a flash memory, in this kind of memory you can only

change bits from 1 to 0 at a particular address,

so a write operation does:

write(A) === write(read(A) && A))

 

try this:

> mini51 read_isp 0x0

0x00000000: 0x00000670

>mini51 write_isp 0x0 0x12345378  

0x00000000: 0x12345378

> mini51 read_isp 0x0     

 0x00000000: 0x00000270

 

to "erase" a part o the memory (set all values to 0xffffffff) 

use:

> flash erase_sector 0 0 1

you can only erase a whole sector (512 bytes) at once.

[sasam]

./progStLink.sh works but write is very, very slow.

...
+ openocd -f interface/stlink-v2.cfg -f target/m051.cfg -c 'program cheali-charger-imaxB6-clone_0.99-20141222_nuvoton-M0517.hex verify reset'
Open On-Chip Debugger 0.9.0-dev-00211-g3da9300 (2014-12-20-01:16)

Licensed under GNU GPL v2
For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter speed: 1000 kHz
adapter_nsrst_delay: 100
Info : clock speed 1000 kHz
Info : STLINK v2 JTAG v19 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2

Info : Target voltage: 3.520000

Info : m051.cpu: hardware has 4 breakpoints, 2 watchpoints

target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000008d0 msp: 0x20000ff0

** Programming Started **
auto erase enabled
Info : device id = 0x10005a00
Info : device name = M0516LBN

Info : bank base = 0x00000000, size = 0x00010000
wrote 34304 bytes from file cheali-charger-imaxB6-clone_0.99-20141222_nuvoton-M0517.hex in 209.095047s (0.160 KiB/s)
** Programming Finished **
** Verify Started **
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000ff0
verified 34060 bytes in 0.250997s (132.518 KiB/s)
** Verified OK **
** Resetting Target **
shutdown command invoked

[Paweł Si]

2014-12-22 2:16 GMT+01:00 sasam <sasa.mi...@gmail.com>:

./progStLink.sh works but write is very, very slow.

wrote 34304 bytes from file cheali-charger-imaxB6-clone_0.99-20141222_nuvoton-M0517.hex in 209.095047s (0.160 KiB/s)

209s, yes, that's quite a lot, I will look on it when I find some free time

(It takes about 30s in my case - but it's also not impressive),

did you menage to program the chip under VMware?

[sasam]

This results is form may raw/native Linux partition (Ubuntu 14.04). Also I tried with VMware with Lubuntu 14.04 but i give up and brake up flash process after cca +10min. On CooCox CooIDE flashing with ST-link/V2 is faster than with Bu-link.

Probably i don't undestand how process of write/read to flash memory work, and i am prety confused with OpenOCD debug log for write or read operation.



 

[Paweł Si]

2014-12-22 16:42 GMT+01:00 sasam <sasa.mi...@gmail.com>:

Dana ponedjeljak, 22. prosinca 2014. 13:06:47 UTC+1, korisnik cheali-charger napisao je:

2014-12-22 2:16 GMT+01:00 sasam <sasa.mi...@gmail.com>:

./progStLink.sh works but write is very, very slow.

wrote 34304 bytes from file cheali-charger-imaxB6-clone_0.99-20141222_nuvoton-M0517.hex in 209.095047s (0.160 KiB/s)

Probably i don't undestand how process of write/read to flash memory work, and i am prety confused with OpenOCD debug log for write or read operation.

hmm... maybe you would like to look into it?

the OpenOCD logs are not important from our perspective,

the only thing that counts is what we log (mini51.c driver) and we don't log anything,

but you can temporary change this by adding:

LOG_WARNING("some info");

in those places:

https://github.com/stawel/openocd/blob/master/src/flash/nor/mini51.c#L355

https://github.com/stawel/openocd/blob/master/src/flash/nor/mini51.c#L379

https://github.com/stawel/openocd/blob/master/src/flash/nor/mini51.c#L406

[sasam]

CooCox Flash mechanism description:

http://www.ie.ksu.edu.tw/data/nuvoton/CooCox%20Tools/HTML/CoFlashGuide/CoFlash_UserGuide_Algorithm.htm

Iz seems that same mechanism is used on some OpenOCD drivers.
https://github.com/stawel/openocd/blob/master/src/flash/nor/stm32f1x.c#L564

[Paweł Si]

Impressive, probably the fasted method, we currently need about 6 times more access (or even more) to do one write. 

but to implement this method you probably would need to write a new flash driver,

Best Regards,

Paweł

[sasam]

On Sunday, December 14, 2014 4:02:26 PM UTC+1, cheali-charger wrote:

Not according to this site, but I'm using eclipse, you need to:

1 .run cmake with the "./bootstrap-arm" command

2. in eclipse: "File"->"Import"->"General"->"Existing Project into Workspace"

3. set: "Select root directory" to your cheali-charger directory, and "Finish"

if you need debugging (patched OpenOCD needed):

4. install: http://gnuarmeclipse.livius.net/blog/openocd-debugging/

5. additionally to "OpenOCD plug-in usage":

   -  in "Debugger"->"OpenOCD setup"->"other options" set to: "-f interface/stlink-v2.cfg -f target/m051.cfg"

   -  in "Debugger"->"GDB client setup"->"executable:" set to "/usr/bin/arm-none-eabi-gdb"

I sucesfuly instaled Eclipse with all necessary plugins on my VMware Lubuntu Linux. Cheali-charger compile well and also debuger (OpenOCD & ST-Link/V2) work well. Only problem is flashing speed, It neeed more than 10min to flash :( .   On real Linux partition flashing last cca 3.5min which is also to slow to be practical.

Reading from flash & RAM and writing to RAM is wery fast, so probaby only flash routine in driver for m051 should be rewriten. If I catch enought time I will try to do somentig :) . Idea is to copy flash routine to microcontoler RAM and than copy data for one or few flash sector in RAM than excucute flash routine on microcontroler to flash data form RAM to flash memory. On M0517 we have 4 KB RAM so I think it will be enough for flash code and flash data for 6 or 7 flash sectors in one pass.

Example for flash routine we can find in CoFlash "flash/source" directory. There are flash routins source code for all suported microcontrolers. M0517 routine is here: drive:\CooCox\CoFlash\flash\source\NUCM051x
I sucesfuly compile this code and use this module with CooFlash, so similar routune can be used in OpenOCD diver for M0517.