programming nuvoton M0517LBN with a ST-Link (STM32F4DISCOVERY board)

[Paweł Si]

It turns out that it's possible to program a nuvoton M0517 CPU charger

with a STM32F4DISCOVERY board.

Unfortunately I wasn't able to disable the flash "security bit" with

this configuration, so the bu-link is still required for the first

flash cleaning.

more info in this thread:

http://www.mikrocontroller.net/topic/309185?page=single

Best Regards,

Paweł

[sasam]

I have one STLink-V2 like this
http://www.aliexpress.com/item/Free-Shipping-1SET-ST-Link-V2-for-STM8S-STM8L-STM32-Cortex-M0-Cortex-M3-SWIM-JTAG/1582945053.html?s=p
but i didn't try to connect it to my charger.

Do you have idea how to map ST-LinkV2 pins to Nuvoton M0517 CPU ?

Best Regards,
Saša

[Paweł Si]

I only connected 3 lines +  Vcc:

(STM32F4discovery)        (charger)

"SWD connector"  

2. SWDCLK               <--> 2. ICE_CLK

3. GND                      <--> 4. GND

4. SWDIO                  <--> 1. ICE_DATA

(and additionally)

Vcc (3.3V)                 <--> 5. Vcc

(there was no Vcc on the "SWD connector")

based on page 15:

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00039084.pdf

so I would say you should use pins 2,4,6,7 on your adapter.

[Paweł Si]

interesting unlocking method:

https://github.com/hackocopter/JD385_Documentation/blob/master/Quad%20Firmware%20Flashing/Readme.md#unlocking-the-controller

[sasam]

ST-LinkV2 work perfectly when M0517 is unlocked. It seem that flashing process on the same freq. is faster then with Bu-link. Other good thing is that TxSoftSerial work over temp sensor port with ST-LinkV2 power only, and LCD display is more readable than with Bu-link power. Last night i downloded an instal Keil mVision V5.12.0.0 and tray to unlock M0517 but unfortunately without success. It is not possible to start debug session when CPU is locked. When CPU in not locked,  unlock procedure work as described on this link. Did you tray to unlock M0517 with your STM32F4DISCOVERY board?

Best Regards,
Saša

[Paweł Si]

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

ST-LinkV2 work perfectly when M0517 is unlocked. It seem that flashing process on the same freq. is faster then with Bu-link. Other good thing is that TxSoftSerial work over temp sensor port with ST-LinkV2 power only, and LCD display is more readable than with Bu-link power. Last night i downloded an instal Keil mVision V5.12.0.0 and tray to unlock M0517 but unfortunately without success. It is not possible to start debug session when CPU is locked. When CPU in not locked

That's bad news, I hoped that we even could download the firmware with some debugger hacking.

 

,  unlock procedure work as described on this link.

Did you tray to unlock M0517 with your STM32F4DISCOVERY board?

not yet, I will play with it this weekend.

[sasam]

Dana utorak, 2. prosinca 2014. 13:18:25 UTC+1, korisnik cheali-charger napisao je:

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

ST-LinkV2 work perfectly when M0517 is unlocked. It seem that flashing process on the same freq. is faster then with Bu-link. Other good thing is that TxSoftSerial work over temp sensor port with ST-LinkV2 power only, and LCD display is more readable than with Bu-link power. Last night i downloded an instal Keil mVision V5.12.0.0 and tray to unlock M0517 but unfortunately without success. It is not possible to start debug session when CPU is locked. When CPU in not locked

That's bad news, I hoped that we even could download the firmware with some debugger hacking.

Maybe we need some older version of Keil. I tried Keil unlock procedure with Bu-link instead of ST-LinkV2, and in that case popup menu (probably from Bu-link driver) appear and suggest full erase.
On ST-LinkV2 i have T_JRST(1) and SWIM_RST(9) pin. I tried to enter Keil debug mode when one of them was connected to RST pin on charger. I am not sure did I try with both or only one. Tonight i will tray again with both.
 

 

,  unlock procedure work as described on this link.

Did you tray to unlock M0517 with your STM32F4DISCOVERY board?

not yet, I will play with it this weekend.

 

I am curious for results
 

[sasam]

Good news!
I sucesfuly erased locked M0517 with Keil, and flash it again with ST-LinkV2 (CooCox CoIDE&CoFlash). RST pin on M0517 I connected to SWIM_RST (pin 9 on my ST-LinkV2), and in Keil debug config I set HW RESET for reset type.

This action I performed with ST-LinkV2 like this: http://www.aliexpress.com/item/Free-Shipping-1SET-ST-Link-st-link-V2-for-STM8S-STM8L-STM32-Cortex-M0-Cortex-M3/1758613434.html

On e-bay you can find somethng like this: http://www.ebay.com/itm/ST-Link-V2-mini-STM8-STM32-Emulator-Downloader-Programming-Unit-Random-Color-/141487196483?pt=LH_DefaultDomain_0&hash=item20f14b4943
Pin out is little bit different but all pin what we need is there, and probably work.

On Aliexpress: http://www.aliexpress.com/premium/ST%25252dlink-V2.html?g=y&needQuery=n&isFreeShip=y&SearchText=ST-link%2BV2&CatId=0&shipCountry=hr&initiative_id=SB_20141202161540&isRtl=yes&SortType=price_asc&filterCat=400103,4099,515&groupsort=1

[Paweł Si]

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

Good news!
I sucesfuly erased locked M0517 with Keil, and flash it again with ST-LinkV2 (CooCox CoIDE&CoFlash). RST pin on M0517 I connected to SWIM_RST (pin 9 on my ST-LinkV2), and in Keil debug config I set HW RESET for reset type.

This action I performed with ST-LinkV2 like this: http://www.aliexpress.com/item/Free-Shipping-1SET-ST-Link-st-link-V2-for-STM8S-STM8L-STM32-Cortex-M0-Cortex-M3/1758613434.html

On e-bay you can find somethng like this: http://www.ebay.com/itm/ST-Link-V2-mini-STM8-STM32-Emulator-Downloader-Programming-Unit-Random-Color-/141487196483?pt=LH_DefaultDomain_0&hash=item20f14b4943
Pin out is little bit different but all pin what we need is there, and probably work.

On Aliexpress: http://www.aliexpress.com/premium/ST%25252dlink-V2.html?g=y&needQuery=n&isFreeShip=y&SearchText=ST-link%2BV2&CatId=0&shipCountry=hr&initiative_id=SB_20141202161540&isRtl=yes&SortType=price_asc&filterCat=400103,4099,515&groupsort=1

A nuvoton programmer for just 5$ is what we needed!

I'm wondering if it's possible to download the firmware with security lock turned on,

some interesting approaches:

1. read flash direct from memory (mrw command)

2. try to read the flash through the ReadViaISP(address) method.

3. try to use the undocumented register: 0x5000c01c

     https://gist.github.com/TheLastMutt/d1c1948acaace7444c1c#file-mini51-cfg-L175

4. maybe try to unlock only the APROM in APUEN in ISPCON

5. most interesting:

    - check if we have access to RAM (address 0x20000000)

    - write some code that can be uploaded to RAM and will read the APROM to memory

    - run the code from RAM

I will to some tests this weekend.

Best Regards,

Paweł

[alex alex]

Hi guys,

So if I buy one of this ST-Link V2 mini, I should be able to erase the locked M0517, but what about flashing it with the cheali-charger alternative firmware? Would it be possible to flash it or I would need the STM32F4DISCOVERY board? 

What other boards can be used for flashing/erasing beside Bu-Link and ST-Link?

Thank you.

[Paweł Si]

2015-01-05 9:32 GMT+01:00 alex alex <undergr...@gmail.com>:

Hi guys,

So if I buy one of this ST-Link V2 mini, I should be able to erase the locked M0517, but what about flashing it with the cheali-charger alternative firmware? Would it be possible to flash it or I would need the STM32F4DISCOVERY board?

You should be able to erase the security lock and flash your device.

 

 

What other boards can be used for flashing/erasing beside Bu-Link and ST-Link?

a good question, probably any device  that supports SWD (Serial Wire Debug)

 

Thank you.

[sasam]

On e-bay auction I win and bought this ST-Link V2: http://www.ebay.com/itm/ST-Link-V2-mini-STM8-STM32-Emulator-Downloader-Programming-Unit-Random-Color-/131368330608?ssPageName=ADME:X:RTQ:US:1123
I upgraded It with last FW and it work perfectly.

Last few days I have been playing with this dongle & OpenOCD under my VMware Lubuntu. I wrote TCL script to flash image (init, erease, flash, validate) and it lasts only 6s (to flash last ARM version of cheali-charger) :-) . Pawel patch for OpenOCD is not needed for this procedure so I hope it can be possible to use last Win version of OpenOCD.

[sasam]

Last few days I have been playing with this dongle & OpenOCD under my VMware Lubuntu. I wrote TCL script to flash image (init, erase, flash, validate) and it lasts only 6s (to flash last ARM version of cheali-charger) :-) . Pawel patch for OpenOCD is not needed for this procedure so I hope it can be possible to use last Win version of OpenOCD.

I successfully flash cheali-charger with windows OpenOCD (0.8.0) & ST-Link V2 on my Win7 laptop. It need only 4s to flash image. For time measurement I used TCL command "clock".
OpenOCD TCL script is the same as on Linux. I must instaled GnuWin32_CoreUtils because in script I am using unix commands "split" and "rm".  Driver for ST-Link V2 is native ST driver (st-link_v2_usbdriver.exe)
Instructions for OpenOCD installation on windows can be found here: http://gnuarmeclipse.livius.net/blog/openocd-install/

I will put more detail in this thread OpenOCD support for nuvoton M0516LBN CPU.

[Paweł Si]

2015-01-15 2:00 GMT+01:00 sasam <sasa.mi...@gmail.com>:

Last few days I have been playing with this dongle & OpenOCD under my VMware Lubuntu. I wrote TCL script to flash image (init, erase, flash, validate) and it lasts only 6s (to flash last ARM version of cheali-charger) :-) . Pawel patch for OpenOCD is not needed for this procedure so I hope it can be possible to use last Win version of OpenOCD.

I successfully flash cheali-charger with windows OpenOCD (0.8.0) & ST-Link V2 on my Win7 laptop. It need only 4s to flash image. For time measurement I used TCL command "clock".

4s - that's really impressive! 

 

OpenOCD TCL script is the same as on Linux. I must instaled GnuWin32_CoreUtils because in script I am using unix commands "split" and "rm".  Driver for ST-Link V2 is native ST driver (st-link_v2_usbdriver.exe)
Instructions for OpenOCD installation on windows can be found here: http://gnuarmeclipse.livius.net/blog/openocd-install/

I will put more detail in this thread OpenOCD support for nuvoton M0516LBN CPU.

Maybe a github project for that? (or some other site)

It would be easier for me to link to it.

Best Regards,

Paweł

[sasam]

Maybe a github project for that? (or some other site)

It would be easier for me to link to it.

Current version of OpenOCD TCL scripts for flashing cheali-charger ARM firmvare to M0517 via ST-Link V2 can be found in my GitHub folder.
After compiling you can go to folder cheali-charger/src/hardware/nuvoton-M0517/targets/imaxB6-clone and start script progStLink2.sh
 
On my desktop PC (XP windows, 2GB RAM, CPU E8400 (2 core)) on VMware Lubuntu it last 8s ( 2s (init & erase) + 6s (copy & verify)) when i start it with progStLink2.sh scripts. When stat manualy it last 6s on Linux and 6s on windows with OpenOCD version for windows.

When I start it on my laptop (Win7, 4GB RAM, i7CPU 4 core) it last only 4s (sometime 5s) on windows, and  6s on VMware Lubuntu (same image as on my desktop PC). Pawel patch for OpenOCD is unnecessary for this scripts, it runs OK on last regular OpenOCD version (0.8.0).

For some reason Win and Linux OpenOCD config scripts for target (M0517) must be different (probably USB driver for ST-Link V2).

Also I put OpenOCD TCL scripts for unlock M0517 it is based on Keil scripts from here: https://github.com/hackocopter/SWD-Hacking/blob/master/KEIL-Flashtools/Mini51flashtools.ini and OpenOCD TCL verson from here: https://gist.github.com/TheLastMutt/d1c1948acaace7444c1c#file-mini51-cfg-L175

[Paweł Si]

Great!

I will test it this weekend,

Best Regards,

Paweł

 

[Илья Савин]

Hello, guys! I'm deeply interested in this topic, you are making a great job!

As for me I've ordered and already received ST link V2. Also i have a Nuvoton based charger with board revision 2. So my plan is'n only to flash it to cheali charger but to make a video or text manual how to do it in a most simple way and gieve it to you to help other people without much knowlege in cortexes and nuvotons. (as for me i'm atmega user)

Yesterday I tried to connect ST link and charger as its described previously and tryed to use a OpenOCD manual to flash it. But on the very first step i received a warning that target_M0517_win.tcl cant be found. In TCL folder this file also not present.

My quiestion is: do we need only follow M0517_flash_tools manual to flash nuvoton by cheali charger. Can you describe steps to flash charger without compiling anythig but using just .hex or .bin ?

[sasam]

You tried on windows or on Linux?
You mention target_M0517_win.tcl so I  assume win.
try:
openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_M0517_win.tcl
or
openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_M0517_win.cfg
rename target_M0517_win.tcl to target_M0517_win.cfg

For windows you must instal GnuWin32_CoreUtils because in TCL script I am using unix commands "split" and "rm".
Put all files from this folder https://github.com/sasam/cheali-charger/tree/linux_flash_test/utils/M0517_flash_tools/tcl in your openocd bin dir
on my XP PC: V:\tmp\openocd-0.8.0\bin then start

openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_M0517_win.cfg

connect to openocd telnet port 4444 for example with putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) (telnet,localhost, port 4444)

for unlock:

source M0517_flash.tcl
ReadConf
EraseChip
WriteConf

for flash:

source M0517_flash.tcl
FlashAprom binary_file_you_wont_to_flash

Dana utorak, 3. veljače 2015. u 08:00:33 UTC+1, korisnik ILIA napisao je:

Hello, guys! I'm deeply interested in this topic, you are making a great job!

As for me I've ordered and already received ST link V2. Also i have a Nuvoton based charger with board revision 2. So my plan is'n only to flash it to cheali charger but to make a video or text manual how to do it in a most simple way and gieve it to you to help other people without much knowlege in cortexes and nuvotons. (as for me i'm atmega user)

Yesterday I tried to connect ST link and charger as its described previously and tryed to use a OpenOCD manual to flash it. But on the very first step i received a warning that target_M0517_win.tcl cant be found. In TCL folder this file also not present.

rename target_M0517_win.cfg to target_M0517_win.tcl
or start scriprs with: openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_M0517_win.cfg

You can also put -s options with folder where you put scripts (M0517_flash.tcl, M0517_unlock.tcl, target_M0517_win.cfg) 

 

My quiestion is: do we need only follow M0517_flash_tools manual to flash nuvoton by cheali charger. Can you describe steps to flash charger without compiling anythig but using just .hex or .bin ?

Which manual? This is only notes...
There is one error in unlock procedure description, I corrected it...

First you must unlok/erase original firmware. It is posible with OpenOCD and this scripts.
For me easiest way to compile and flash on Win is to use CooCox. I tried to compile cheali-charger manually from comand line on real win (not cygwin) but without success. Probably cmake for windows and Linux are not fully compatible. On windows it generate makefiles which are not sutable to compile cheali-charger from command line. I did not try with eclipse for windows.
 

[ILIA]

I've tried openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_M0517_win.tcl and it woun't starts as service, here, what i have:

 

D:\get\openocd-0.8.0\bin>openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_
M0517_win.tcl
Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
0
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.471484
Error: init mode failed
in procedure 'transport'
in procedure 'init'


D:\get\openocd-0.8.0\bin>

that both for 5v and 3v. In st link i have "FW version V2.J23.S4 STM32+STM8 Debugger"

connection is:

charger - st-link

1. ICE_DATA - 6.T_JTMS/T_SWDIO

2. ICE_CLK - 4.T_JTCK/T_SWCLK

3. ICE_RST - 9. SWIM_RST  (i tried when connected and not)

4. GND - 7. GND

5. VCC - 2. 3V3

Reference pictures i've used:

[sasam]

Did you install USB driver from here: http://www.st.com/web/catalog/tools/FM147/SC1887/PF258167#  ?

I connect VCC to 5V, RST is not connected

FW version: V2.J19.S4 JTAG+SWIM Debugger


V:\tmp\openocd-0.8.0\bin>openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_M0517_win.tcl

Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
0
Info : This adapter doesn't support configurable speed

Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
Error: open failed

in procedure 'transport'
in procedure 'init'

From some reason openocd faild (probably because I try to get firmvare version before). Afer that I disconnet St-link fromUSB and connect again.

V:\tmp\openocd-0.8.0\bin>openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_M0517_win.tcl

Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
0
Info : This adapter doesn't support configurable speed

Info : STLINK v2 JTAG v19 API v2 SWIM v4 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 3.256011
Info : M0517.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : accepting 'telnet' connection from 4444

This test is with this http://www.ebay.com/itm/131368330608?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT device

[sasam]

FW version is different "V2.J23.S4 STM32+STM8 Debugger" vs "V2.J19.S4 JTAG+SWIM Debugger"
Try with linux version for target target_MO517_linux.tcl or try to change someting inside this file.

[sasam]

I downloaded "ST-LINK/V2 firmware upgrade" from here  http://www.st.com/web/catalog/tools/FM147/SC1887/PF258194
Flash new FW on my ST-Link/V2 and now I have FW: "V2.J21.S4 STM32+STM8 Debugger"

openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_M0517_win.tcl

work as expected

[sasam]

finally I installed STM32 ST-LINK Utility_v3.5.exe then flash last FW for that.
Now I have FW: "V2.J23.S4 STM32+STM8 Debugger" and it work as expected

V:\tmp\openocd-0.8.0\bin>openocd-0.8.0.exe -f interface/stlink-v2.cfg -f target_M0517_win.tcl

Open On-Chip Debugger 0.8.0 (2014-04-28-08:39)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
0
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v23 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2

Info : Target voltage: 3.255446

[Paweł Si]

Hi Sasam,

I finally tested your implementation and I must say I'm speechless!

I didn't had to configure anything, I just run ./progStLink2.sh,

programming took 2.5s on linux (vs. 20s for my solution).

It's ideal for debugging!

can I marge this into my branch?

hm... although I'm not sure if your implementation should be buried in the

cheali-charger source tree, it's just to good for that,

You probably should make a separate project for it,

or propose it  to the openOCD project.

Best Regards,

Paweł

[sasam]

Dana subota, 7. veljače 2015. u 16:42:16 UTC+1, korisnik cheali-charger napisao je:

Hi Sasam,

I finally tested your implementation and I must say I'm speechless!

I didn't had to configure anything, I just run ./progStLink2.sh,

programming took 2.5s on linux (vs. 20s for my solution).

It's ideal for debugging!

 

 Probably it can run little faster if you remove all unnecessary puts messages, and time measurement function inside M0517_flash.tcl script.
 

can I marge this into my branch?

 

Of course, you can merge, change and improve it.
I don't know is this folder: https://github.com/sasam/cheali-charger/tree/linux_flash_test/utils/M0517_flash_tools right place for this code. There is, source code for ARM-flash function, TCL script and config for OpenOCD.
In https://github.com/sasam/cheali-charger/tree/linux_flash_test/src/hardware/nuvoton-M0517/targets/imaxB6-clone I put OpenOCD TCL scripts &  config, ARM-flash binary and bash script for backup & flash. Now we have same files on 2 place, probably this is not good idea.
 

hm... although I'm not sure if your implementation should be buried in the

cheali-charger source tree, it's just to good for that,

You probably should make a separate project for it,

or propose it  to the openOCD project.

Before I put this code in my cheali-charger source tree I create repository on my Github: https://github.com/sasam/M0517_flash_tools
unfortunately documentation is still missing.

My first idea was to implement idea of "self flash programming" as patch to you OpenOCD patch/driver for M051x controllers. But after 2-3 days I give up from this approach and focus on OpenOCD TCL script. First test was promising because i soo that standard OpenOCD function for read from file and write to SRAM work fairly quickly.
There is many strange thing in this OpenOCD TCL implementation. For example the is no function to read binary file, so i decided use some Unix function for help.

Also some function send output to stderr and some to stdout and some to booth. On some function you must put prefilx ocd_ if you wish output to stdout...

Finlay I succeed with TCL. I think it is good solution becaus it work with native OpenOCD version without patch.
On my VMware LUbuntu Linux if flash for 6s vs +900s with you patch version of OpenOCD.

Best Regards,
Saša
 

[Paweł Si]

2015-02-07 23:21 GMT+01:00 sasam <sasa.mi...@gmail.com>:

Of course, you can merge, change and improve it.
I don't know is this folder: https://github.com/sasam/cheali-charger/tree/linux_flash_test/utils/M0517_flash_tools right place for this code. There is, source code for ARM-flash function, TCL script and config for OpenOCD.
In https://github.com/sasam/cheali-charger/tree/linux_flash_test/src/hardware/nuvoton-M0517/targets/imaxB6-clone I put OpenOCD TCL scripts &  config, ARM-flash binary and bash script for backup & flash. Now we have same files on 2 place, probably this is not good idea.

hmm... I've noticed that  we can only  flash *.bin files, and I'm only publishing hex files,

as far as I understand it's because we are splitting the file with the "split" bash command?  

I've also looked at the OpenOCD documentation:

 http://openocd.sourceforge.net/doc/html/General-Commands.html

"Command: load_image filename address [[bin|ihex|elf|s19] min_addr max_length]"

maybe this function can be used to split the file?

[sasam]

I looked this function but i didn't find solution how-to load each part of image file to RAM for flash. What do you think for idea to write small program for split bin or hex file into parts for flash ? or just one function for conversion hex file to binary file.

[sasam]

if you have ARM compiler...
conversion hex => bin
arm-none-eabi-objcopy.exe -I ihex -O binary cheali-charger-imaxB6-clone_0.99-20150124_nuvoton-M0517.hex cheali-charger-imaxB6-clone_0.99-20150124_nuvoton-M0517.bin

if not maybe some of this work:
http://sourceforge.net/projects/hex2bin/
http://gnuwin32.sourceforge.net/packages/hex2bin.htm

or this one: http://srecord.sourceforge.net/

[Paweł Si]

2015-02-19 4:11 GMT+01:00 sasam <sasa.mi...@gmail.com>:

Dana četvrtak, 19. veljače 2015. u 03:39:01 UTC+1, korisnik sasam napisao je:

Dana srijeda, 18. veljače 2015. u 21:03:04 UTC+1, korisnik cheali-charger napisao je:

2015-02-07 23:21 GMT+01:00 sasam <sasa.mi...@gmail.com>:

Of course, you can merge, change and improve it.
I don't know is this folder: https://github.com/sasam/cheali-charger/tree/linux_flash_test/utils/M0517_flash_tools right place for this code. There is, source code for ARM-flash function, TCL script and config for OpenOCD.
In https://github.com/sasam/cheali-charger/tree/linux_flash_test/src/hardware/nuvoton-M0517/targets/imaxB6-clone I put OpenOCD TCL scripts &  config, ARM-flash binary and bash script for backup & flash. Now we have same files on 2 place, probably this is not good idea.

hmm... I've noticed that  we can only  flash *.bin files, and I'm only publishing hex files,

as far as I understand it's because we are splitting the file with the "split" bash command?  

I've also looked at the OpenOCD documentation:

 http://openocd.sourceforge.net/doc/html/General-Commands.html

"Command: load_image filename address [[bin|ihex|elf|s19] min_addr max_length]"

maybe this function can be used to split the file?

I looked this function but i didn't find solution how-to load each part of image file to RAM for flash. What do you think for idea to write small program for split bin or hex file into parts for flash ? or just one function for conversion hex file to binary file.

yesterday I played a little bit with your code and I suspect it can be done with this "load_image" method

the only problem is how to calculate: "address", "min_addr"

I will do more test this weekend

[sasam]

As well for CooCox Flash utility we need binary image to flash, so maybe the simplest solution will be to provide .bin image for nuvoton-M0517 chargers.
What is the reason to keep .hex images instead of .bin images?

[Dmitry]

Hello everyone !
Please tell me how to connect the ST-link V2 r this board?

Kind regards
Dmitry.

[jarno83]

I connected like this:

ICE_DATA <--------->    SWDIO

ICE_CLK   <---------->    SWCLK

ICE_RST   <---------->   RST

GND          <---------->   GND

VCC          <---------->   5V Vcc

Take a look at this tread also - https://groups.google.com/forum/#!topic/cheali-charger/P8eFl5f6jpc

[Dmitry]

пятница, 20 февраля 2015 г., 19:05:55 UTC+3 пользователь jarno83 написал:

 ICE_RST = nRST ?

Whether I understood you correctly?

[jarno83]

I have that motherboard (2.0) - https://github.com/stawel/cheali-charger/blob/master/docs/imaxB6_nuvoton-M0517/imaxB6-clone-nuvoton-front.jpg

In your picture you have 1.8. I won't give my head for that, but seams that layout and pins are the same.

[Dmitry]

пятница, 20 февраля 2015 г., 21:13:26 UTC+3 пользователь jarno83 написал:

I have that motherboard (2.0) - https://github.com/stawel/cheali-charger/blob/master/docs/imaxB6_nuvoton-M0517/imaxB6-clone-nuvoton-front.jpg

In your picture you have 1.8. I won't give my head for that, but seams that layout and pins are the same.

 These pins are involved?
Kind regards
  Dmirty!

[jarno83]

Seams the same... you can check it with multimeter if needed. More info and history of getting cheali charger to M0517 -  https://groups.google.com/forum/#!msg/cheali-charger/VATJQ4-GpVE/E-T_Mzhl3mgJ

Your flashing the chip removed from pcb?

[Dmitry]

суббота, 21 февраля 2015 г., 0:29:04 UTC+3 пользователь jarno83 написал:

Seams the same... you can check it with multimeter if needed. More info and history of getting cheali charger to M0517 -  https://groups.google.com/forum/#!msg/cheali-charger/VATJQ4-GpVE/E-T_Mzhl3mgJ

Your flashing the chip removed from pcb

I've already rung tester and photos in my first message shown compliance pins M0517 and software connector on the charger
1 -> 31 pin ICE_DAT
2 -> 32 pin ICE_CLK
3 -> 4 pin nRST
4 -> 6 pin AVss (GND)
5 -> 41 and 42 pins AVdd, Vdd (+ 5V)

https://drive.google.com/file/d/0B_j8VHf6GGn0SHY0b2lYYWxkN2c/view?usp=sharing

Programmer ST-link V2 has terminals
1 ---> RST
2 ---> SWCLK
3 ---> SWIN
4 ---> SWDIO
5,6 ---> GND
9,10 ---> 5.0V
and 4-wire loop. Do I need another wire to +5 volts or power feed from the board?
How to connect the ST-Link to the charger?

Kind regards!

[jarno83]

I added pic how I made my connections. Didn't connect anything else.

Powered the board with 5V from st-link dongle.

I hope it helps.

[Dmitry]

суббота, 21 февраля 2015 г., 2:18:07 UTC+3 пользователь jarno83 написал:

I added pic how I made my connections. Didn't connect anything else.

Powered the board with 5V from st-link dongle.

I hope it helps.

 Thank U!
kind regards
  Dmitry

[Paweł Si]

I've added a *.bin file for this charger to:
https://github.com/stawel/cheali-charger/blob/master/hex/unstable/

You will probably need it.

Best Regards

Paweł

[Dmitry]

Hi !
Unable to login.
https://drive.google.com/file/d/0B_j8VHf6GGn0M1NZMTAzRnZvRWM/view?usp=sharing
Connect the programmer to the charger starts charging, should it be?
https://drive.google.com/file/d/0B_j8VHf6GGn0VmtvdUZ4SWlydXM/view?usp=sharing

Kind regards
Dmitry

[sasam]

You wont to unlock charger of flash new FW?

[Dmitry]

вторник, 24 февраля 2015 г., 4:22:59 UTC+3 пользователь sasam написал:

You wont to unlock charger of flash new FW?

 Hi!
Yes, I want to erase and flash cheali-charger. If possible, read and save the original firmware, but I think I have it is unlikely to succeed without help, I have no experience with STM32. Have some experience with the MC AVR, but I got Nuvoton.
kind regards
Dmitry.

[sasam]

As I know it is not possible to restore original FW. For unlock you must erase original FW.
Few days ago Pawel introduce patch for M0517_flash.tcl which add support for hex file and also eliminate need for unix commands which I used.

I will try to write small script for win and linux to automate OpenOCD erase process, and maybe flash process for win.
Existing script for automate flash on linux is OK.

Best regards,
Saša

I thing that RST line on ST-LinkV2 is not needed to be connected. But I will try again when will try to write automation script for erase & unlock.

[Dmitry]

вторник, 24 февраля 2015 г., 18:28:56 UTC+3 пользователь sasam написал:

As I know it is not possible to restore original FW. For unlock you must erase original FW.
Few days ago Pawel introduce patch for M0517_flash.tcl which add support for hex file and also eliminate need for unix commands which I used.

I will try to write small script for win and linux to automate OpenOCD erase process, and maybe flash process for win.
Existing script for automate flash on linux is OK.

Best regards,
Saša

I thing that RST line on ST-LinkV2 is not needed to be connected. But I will try again when will try to write automation script for erase & unlock.

 Hi!

SASAM, tried without RST, anyway ST-Link sees no chip.
Maybe the whole thing in the programmer - it does not work? And I check it I can not, I have no other MC ARM.

Best regards
Dmitry/

[sasam]

Did you instal last STM32 ST-LINK Utility_v3.5.exe and flash last FW on your ST-LINK V2 ?
When you connect it on PC what you see in device manager ?
 

[pschwed...@googlemail.com]

Hi guys,

first of all, thank you for your exciting work! This is very interesting for me.

I want to ask for help, though.

I have bought an ST-LINK V2 and connected it to my Nuvoton board as per description. The STLINK shows a green light and the charger powers up and then shows me an input vol error (I guess that's expected).

However, I cannot connect to it. Everything works up to the point when I try to launch openocd with the configuration files provided.

Now, since I wanted to contribute a litte to the documentation I have started to write a small howto, this is how it looks so far (and is what I did so far)

I have to say that I work on OS X 10.10

----

install Xcode from AppStore

open Xcode and install additional components (if open first time)

you may close Xcode and open Terminal

sudo xcodebuild -license

#enter your password

#press space until you reach the bottom of the license

#type agree and confirm

xcode-select --install

#confirm installation of command-line tools in window that pops up

download MacPorts for OS X 10.10 Yosemite (or whatever version of OS X you are using)

# click on the installer and make a standard install (it can take a while)

go back to Terminal

sudo port install libtool automake autoconf pkgconfig wget cmake boost libconfuse swig-python texinfo texlive

#enter your password if prompted

#wait for installation to complete (can (and should!) take a very long time)

curl -L https://sourceforge.net/p/gnuarmeclipse/openocd/ci/gnuarmeclipse/tree/gnuarmeclipse/scripts/build-openocd-osx.sh?format=raw -o ~/Downloads/build-openocd-osx.sh

bash ~/Downloads/build-openocd-osx.sh

this will create an installer in your home folder ▸ Work ▸ openocd ▸ output

execute and install it. then go back to terminal

/Applications/GNU\ ARM\ Eclipse/OpenOCD/bin/openocd --version

this should give an output like this:

GNU ARM Eclipse 64-bit Open On-Chip Debugger 0.8.0 (2015-02-24-15:24)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

if you see this, you can delete that Work folder by typing

rm -rf ~/Work/openocd/

this does not remove the Work folder (since maybe some people actually had one before and don’t want to delete it.. but it removes everything else we just stored there

cd ~/Work/

git clone https://github.com/sasam/M0517_flash_tools.git

----

now, launching 

/Applications/GNU\ ARM\ Eclipse/OpenOCD/bin/openocd -f interface/stlink-v2.cfg -f target_MO517_linux.tcl 

gives me

GNU ARM Eclipse 64-bit Open On-Chip Debugger 0.8.0 (2015-02-24-15:24)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

Error: Invalid command argument

Runtime Error: embedded:startup.tcl:20: -chain-position required when creating target

in procedure 'script' 

at file "embedded:startup.tcl", line 58

in procedure 'target' called at file "target_MO517_linux.tcl", line 37

in procedure 'ocd_bouncer' 

at file "embedded:startup.tcl", line 20

and trying the win configuration script gives me

GNU ARM Eclipse 64-bit Open On-Chip Debugger 0.8.0 (2015-02-24-15:24)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

0

Info : This adapter doesn't support configurable speed

Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 3.215213

Error: init mode failed

in procedure 'transport'

in procedure 'init'

the win configuration seems to work a little better, you can see it has detected the STLINK and then cannot connect to the processor. As to why it cannot find the -chain-position argument in the linux script, I wanted to ask for help. This does not make any sense for me. It seems I am severely stuck at this point.

Thank you,

Philipp

[sasam]

Dana srijeda, 25. veljače 2015. u 11:16:40 UTC+1, korisnik pschwed...@googlemail.com napisao je:

Hi guys,

first of all, thank you for your exciting work! This is very interesting for me.

I want to ask for help, though.

I have bought an ST-LINK V2 and connected it to my Nuvoton board as per description. The STLINK shows a green light and the charger powers up and then shows me an input vol error (I guess that's expected).

However, I cannot connect to it. Everything works up to the point when I try to launch openocd with the configuration files provided.

Now, since I wanted to contribute a litte to the documentation I have started to write a small howto, this is how it looks so far (and is what I did so far)

I have to say that I work on OS X 10.10

----

Unfortunately I have only XP win, Win 7 & Linux machine to tray. Actually i don't know (exactly) what init script for target cpu do. I take a look on some exsisting OCD target scripts for cortex_m family and combine them to work on my win and Linux PC.
 
 

[pschwed...@googlemail.com]

Yes, I know that, I have read the whole thread. OSX uses a Unix core so should be identical to Linux.

to rule out that there is an operating system problem I have tried it with Win7. I have installed the drivers and updated the firmware of STLink V2 to the latest version.

It gives me exactly the same error that I postet above and I believe it is exactly the same error that Dmitri has.

I am sorry, but it just does not work. The output is exactly the same that OSX gives me

Best,

Philipp

[Dmitry]

среда, 25 февраля 2015 г., 12:40:18 UTC+3 пользователь sasam написал:

Did you instal last STM32 ST-LINK Utility_v3.5.exe and flash last FW on your ST-LINK V2 ?
When you connect it on PC what you see in device manager ?
 

Hi!

Yes, I installed and updated FW. In Device Manager, the programmer is determined

[jarno83]

Take a look at this little how to - https://github.com/stawel/cheali-charger/blob/master/docs/Flashing%20m0517.doc

it says what you have to do with your last error: 

and trying the win configuration script gives me

GNU ARM Eclipse 64-bit Open On-Chip Debugger 0.8.0 (2015-02-24-15:24)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

0

Info : This adapter doesn't support configurable speed

Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 3.215213

Error: init mode failed

in procedure 'transport'

in procedure 'init'

[Paweł Si]

Hi,

2015-02-25 11:16 GMT+01:00 <pschwed...@googlemail.com>:

 

I have to say that I work on OS X 10.10

the win configuration seems to work a little better, you can see it has detected the STLINK and then cannot connect to the processor. As to why it cannot find the -chain-position argument in the linux script, I wanted to ask for help. This does not make any sense for me. It seems I am severely stuck at this point.

 

I did a little bit research and it looks like the  target_M0517_win.cfg file works also on linux for openocd <= 0.8

the target_MO517_linux.cfg file works probably only for openocd >= 0.9 which is not released yet,

but the source code can be downloaded from http://openocd.sourceforge.net/repos/ 

Best Regards,

Paweł

[pschwed...@googlemail.com]

Take a look at this little how to - https://github.com/stawel/cheali-charger/blob/master/docs/Flashing%20m0517.doc

it says what you have to do with your last error: 

This was exactly what I needed, THANK YOU! After reading that (and doing some crazy grounding and ungrounding of the RST pin), it finally worked.

I will do the beer step now and then start testing this software. You'll hear from me.

As for the openOCD version thing, that now also makes sense. I saw that there is even a commit that might make everything much simpler, so exciting times are to come ;)

Cheers,

Philipp 

[sasam]

I check and I really have OpenOCD 0.9.0 on my VMvare Linux.

$ openocd --version
Open On-Chip Debugger 0.9.0-dev-00211-g3da9300-dirty (2014-12-23-00:05)

Licensed under GNU GPL v2
For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html

Sorry for confusion with target config files :(
I forget that I copy and compiled Pawel's patched version od OpenOCD which is based on last development version.
I think that target configuratin difference are in relation with drivers (native Linux and ST).

When I have problem with ST-Link error I just unplug dongle from USB port and connect again. In next attempt it usually work as expected.

Best Regards,
Saša

[Christoffer Nilsson]

Is this the correct pinout for the nuvoton processor?

https://groups.google.com/group/cheali-charger/attach/2f140ccac893d9e4/M051x_pin.png?part=0.5

Im going to have to trace down the programming pins from the cpu. On my Turnigy 4x6s charger.

Whats the number of the pins im looking for?

Den lördag 29 november 2014 kl. 23:08:32 UTC+1 skrev cheali-charger:

It turns out that it's possible to program a nuvoton M0517 CPU charger

with a STM32F4DISCOVERY board.

Unfortunately I wasn't able to disable the flash "security bit" with

this configuration, so the bu-link is still required for the first

flash cleaning.

more info in this thread:

http://www.mikrocontroller.net/topic/309185?page=single

Best Regards,

Paweł

[Виталий Широков]

пятница, 17 апреля 2015 г., 19:31:39 UTC+3 пользователь Christoffer Nilsson написал:

 http://datasheet.octopart.com/M0516LBN-Nuvoton-datasheet-27584010.pdf

You need 4, 17, 30, 31, 41 pins.

[Christoffer Nilsson]

Thanks.

Seems im going to have to access 4,30 and 31 on the actuall proccessor pins.  There isnt any exposed points for those
Thats way beyond my soldering skills, so i might just end up having to trash the charger. :(

[Christoffer Nilsson]

High resolution photo of the processor and its traces.
Pin 30 and 31 seems to be routed to some kind of component with 6 pins, labeled 101.

Will see if i can manage to solder on some wires tonight. If not it goes into the trash bin.

[Christoffer Nilsson]

Wired it up, However, is it correct that Vdd is connected to the 3.3v pad on the charger? i had 1 ohm resistance between the pad, and the vdd pin.
Whereas the 5v pad on the bottom had infinity resistance towards Vdd.

I don't want to fry the processor now that iv managed to do the soldering.

[Paweł Si]

2015-04-18 20:11 GMT+02:00 Christoffer Nilsson <xer...@gmail.com>:

Wired it up, However, is it correct that Vdd is connected to the 3.3v pad on the charger? i had 1 ohm resistance between the pad, and the vdd pin.
Whereas the 5v pad on the bottom had infinity resistance towards Vdd.

I don't want to fry the processor now that iv managed to do the soldering.

I'm afraid it's not a nuvoton M0517 CPU.

[Christoffer Nilsson]

Well that sucks, going to have to trash it then.
What is it that tells its not a nuvuton? the vdd being connected to the 3.3v pad?

[Paweł Si]

2015-04-18 20:38 GMT+02:00 Christoffer Nilsson <xer...@gmail.com>:

Well that sucks, going to have to trash it then.
What is it that tells its not a nuvuton? the vdd being connected to the 3.3v pad?

1. our CPU's are labeled - but maybe yours is just a cheaper copy

2. the nuvoton M0517 is powered by 5V - but it can also run at 3.3V so it's not very important

3. in M0517 pins 4, 30, 31  (nRST,  ICE_CLK , ICE_DAT) go straight to the programming connector,

  in your case they go to a resistor (resistor ladder - the 101 element) and they probably are used to control the LCD.

4. some pins are not used  in M0517 (not connected)

    - pins: 5,7, 38, 39, 40, 48

    - a full description of the pins is in: https://github.com/stawel/cheali-charger/blob/master/src/hardware/nuvoton-M0517/generic/50W/imaxB6-pins.h  

5. you could also check  GND (Vss), Vcc, XTAL2 , XTAL1, LDO_CAP  if they are where they should be

hm... maybe you could ask your seller what kind of CPU this is?

[Christoffer Nilsson]

Its from hobbyking, so trying to get the cpu information from them is useless. :(

[Andrew Frewer]

On Saturday, November 29, 2014 at 4:08:32 PM UTC-6, cheali-charger wrote:

It turns out that it's possible to program a nuvoton M0517 CPU charger

with a STM32F4DISCOVERY board.

Unfortunately I wasn't able to disable the flash "security bit" with

this configuration, so the bu-link is still required for the first

flash cleaning.

more info in this thread:

http://www.mikrocontroller.net/topic/309185?page=single

Best Regards,

Paweł

I am using an STM8S discovery kit, which is supposed to be st-link compatible. I've gotten the pinout from http://www.gniibe.org/memo/development/gnuk/hardware/stlinkv2-stm8s-discovery.html and soldered on a header.

What extra steps did you have to do for your Discovery board? I'm having trouble getting mine recognized as an ST-Link.

Thanks! 

[alex alex]

Hi Andrew,

I'm not strong in all these stuff, but I doubt it will work. Your board is STM8S but STM32 is needed, though I might be wrong.

Regards,

[Andrew Frewer]

The STM8S discovery board has an STM32 that is used for programming the STM8S.

[ILYA VETROV]

Mozet komu prigoditsya

Video of the firmware using the ST-Link V2: https://youtu.be/ewDA9arMTUQ

Video Review firmware cheali-charger: https://youtu.be/2KG_h-zr2rY

Razrabotchikov dannoj proshivki proshu dat svoi kontaktj, oxhen nuzna vasha pomosh

[Sven N.]

Hello,

I have the ST-Link v2 with the latest firmware (V2.J24.S4). I'm on Windows 10 64bit and use openocd-0.9.0.

When starting openocd in the bin directory, I get the following error:

$ ./openocd.exe -f ../scripts/interface/stlink-v2.cfg -f target_M0517_win.cfg

Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)

Licensed under GNU GPL v2

For bug reports, read

        http://openocd.org/doc/doxygen/bugs.html

Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.

Warn : Transport "hla_swd" was already selected

Error: The selected transport doesn't support this target

embedded:startup.tcl:21: Error: invalid command name "M0517.cpu"

in procedure 'script'

at file "embedded:startup.tcl", line 60

in procedure 'target' called at file "target_M0517_win.cfg", line 13

in procedure 'ocd_bouncer'

at file "embedded:startup.tcl", line 21

Any idea what's wrong?

Regards,

-Sven

[Paweł Si]

Try the linux version:

$ ./openocd.exe -f ../scripts/interface/stlink-v2.cfg -f target_M0517_linux.cfg

if you are using  openocd-0.9.0 you can also try this (unfortunately it's much slower):

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

[sasam]

Linux version is actually a version that works on Openocd-0.9.x, and a win is for for Openocd-0.8.x

When I start playing with this I compiled Openocd on my Linux box with Pavel patch for M0517. On my PC this version worked, but very slow on VMmware Linux, and little faster on native Linux but still to slow to be practical. I decided to try with tcl scripting and native ARM binary modul for basic flash function. This approach work great (faster than standard flash SW) on my Linux so I decided to port this script also on my windows Openocd. To make things work on windows and Linux, I had to write a different config files for winows-e and for Linux. I didn't understand why this scripts must be different. I think it is because Linux and window use different drivers, but this is not truth.

later I realized that I had different Openocd version on my windows and Linux. When I compiled OpenOCD I grab beta version od Openocd 0.9.x, and on win I had Openocd 0.8.0.

When the official version of Openocd 0.9.0 was released I instaled it on my windows machine and it work well with conf file: target_M0517_linux.cfg

In principle good idea will be to rename this config files to something like this:

target_M0517_win.cfg => target_M0517_0.8.x.cfg

target_M0517_linux.cfg => target_M0517_0.9.x.cfg

Best regards,

saša

[Sven N.]

I tried it with conf file target_M0517_linux.cfg and got this:

$ ./openocd.exe -f ../scripts/interface/stlink-v2.cfg -f target_MO517_linux.cfg

Open On-Chip Debugger 0.9.0 (2015-05-19-12:06)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/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 : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748

Info : using stlink api v2

Info : Target voltage: 3.189041
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'

Has anyone else had this issue (and solved it)?

[Sven N.]

Same error with  ../scripts/target/m051.cfg

[sasam]

Check wiring.

You need SWDIO(2), SWCLK(6) and GND (4). On this pictures I use 5V power because i didn't connect main power, and this 5V from ST-LinkV2 is enough for flashing and basic functionality test.

Dana 

nedjelja, 6. prosinca 2015. u 22:30:16 UTC+1, korisnik Sven N. napisao je:

Same error with  ../scripts/target/m051.cfg

[Kim Benn]

Are you sure that you have made a "manual hardware reset" on the IMAX B6. The trick is described here https://groups.google.com/forum/#!topic/cheali-charger/P8eFl5f6jpc

 

Den søndag den 6. december 2015 kl. 22.30.16 UTC+1 skrev Sven N.:

Same error with  ../scripts/target/m051.cfg

[Sven N.]

Am Montag, 7. Dezember 2015 22:33:48 UTC+1 schrieb Kim Benn:

Are you sure that you have made a "manual hardware reset" on the IMAX B6. The trick is described here https://groups.google.com/forum/#!topic/cheali-charger/P8eFl5f6jpc

 

OK, I finally had some time again to solve this issue and I succeeded at last.

 Setting: Ubuntu 16.04 amd64 with standard openocd package

Steps:

1. Clone repository with --recursive option:
   $ git clone --recursive https://github.com/stawel/cheali-charger.git

2. Change to directory cheali-charger/utils/M0517_flash_tools/tcl

3. Create a symlink to the firmware you want to flash.
  $ ln -s ../../../hex/cheali-charger-imaxB6-clone_2.00-e10.3.12-20160613_nuvoton-M0517.bin m0517.bin

4. Next, unlocking the CPU:
   Connect the RST pin of the charger to one of the GND pins (pin 3 or 4) of the ST-Link v2 instead of the RST pin (pin 1).
  The other pins are connected as follows (charger to ST-Link v2): DAT to SWDIO (pin 2), CLK to SWCCLK (pin 6), GND to GND (pin 3), VCC to 5.0V (pin 10)

5. Plug in the st-link v2 into the USB port. The display of the charger will be illuminated but blank.
 
6. Start openocd:
  $ openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f target_MO517_linux.cfg

The output looks like this:

Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)

Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/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 : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.189041
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'

7. Keep the ST-Link v2 connected to the USB port. Unplug the RST pin connected to GND and reconnect it a couple of times. Also start openocd a couple of times.

8. Connect the RST pin to the RST pin (pin 1).

9. Now, when you start openocd again (see step 6) the output will look different:

Open On-Chip Debugger 0.9.0 (2015-09-02-10:42)

Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/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 : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.189041

Info : M0517.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : accepting 'telnet' connection on tcp/4444

10. Open another terminal window and connect to openocd:
  $ telnet localhost 4444

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger

11. Unlock the CPU by entering 4 commands:

source M0517_unlock.tcl
ReadConf
EraseChip
WriteConf

The output will look like this:

> source M0517_unlock.tcl
EraseChip
> ReadConf
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0x20000fe0
> EraseChip
> WriteConf
target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0x20000fe0

12. Now you are ready to flash the firmware. Issue these two commands:

source M0517_flash.tcl
FlashAprom m0517.bin

The output will look like this:

address 0x00000000 length 0x0000893c
verified 35132 bytes in 0.000404s (84922.266 KiB/s)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0xfffffffe msp: 0xfffffffc
276 bytes written at address 0x20000000
downloaded 276 bytes in 0.005915s (45.567 KiB/s)
sp (/32): 0x20001000
pc (/32): 0x20000000
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x41000000 pc: 0x20000048 msp: 0x20001000
r0 (/32): 0x00000000
r0 (/32): 0x00000000
r1 (/32): 0x00000045
sp (/32): 0x20001000
pc (/32): 0x20000058
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x200000a2 msp: 0x20000fec
r0 (/32): 0x00000000
3584 bytes written at address 0x20000120
downloaded 3584 bytes in 0.064183s (54.532 KiB/s)
r0 (/32): 0x00000000
r1 (/32): 0x00000E00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
3584 bytes written at address 0x20000120
downloaded 3584 bytes in 0.063652s (54.986 KiB/s)
r0 (/32): 0x00000E00
r1 (/32): 0x00000E00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
3584 bytes written at address 0x20000120
downloaded 3584 bytes in 0.064372s (54.371 KiB/s)
r0 (/32): 0x00001C00
r1 (/32): 0x00000E00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
3584 bytes written at address 0x20000120
downloaded 3584 bytes in 0.064482s (54.279 KiB/s)
r0 (/32): 0x00002A00
r1 (/32): 0x00000E00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
3584 bytes written at address 0x20000120
downloaded 3584 bytes in 0.064474s (54.285 KiB/s)
r0 (/32): 0x00003800
r1 (/32): 0x00000E00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
3584 bytes written at address 0x20000120
downloaded 3584 bytes in 0.064220s (54.500 KiB/s)
r0 (/32): 0x00004600
r1 (/32): 0x00000E00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
3584 bytes written at address 0x20000120
downloaded 3584 bytes in 0.064308s (54.426 KiB/s)
r0 (/32): 0x00005400
r1 (/32): 0x00000E00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
3584 bytes written at address 0x20000120
downloaded 3584 bytes in 0.064012s (54.677 KiB/s)
r0 (/32): 0x00006200
r1 (/32): 0x00000E00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
3584 bytes written at address 0x20000120
downloaded 3584 bytes in 0.063896s (54.777 KiB/s)
r0 (/32): 0x00007000
r1 (/32): 0x00000E00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
2876 bytes written at address 0x20000120
downloaded 2876 bytes in 0.051605s (54.425 KiB/s)
r0 (/32): 0x00007E00
r1 (/32): 0x00000C00
r2 (/32): 0x20000120
sp (/32): 0x20001000
pc (/32): 0x200000AE
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000010c msp: 0x20000ff4
r0 (/32): 0x00000000
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000ff4
verified 35132 bytes in 0.171986s (199.485 KiB/s)

Congratulations, you are done flashing!

Cheers,
-Sven

[Gio 342]

Thanks for the procedure, is there a way to make a backup before flashing? thank you