I've been using PonyProg for years and this is the first time I have a problem. I got some Arduino Nano (ATmega328p) boards and wanted to backup the bootloader before erasing the chip. I was surprised when I saw BOOTSZ1, BOOTSZ0 and BOOTRST are unchecked (unprogrammed, bit = 1) and the bootloader does work!! The bootloader worked even after uploading the first .hex meaning the code does NOT start at 0x0000 and eventually reaches the bootloader. By checking the fuse bits with Avrdude and usbasp programmer I got: Extended=0x07, High=0xda and Low=0xff meaning BOOTRST and BOOTSZ1 *ARE* programmed (checked, bit = 0). Then I noticed PonyProg is showing BODLEVEL0 and BODLEVEL2 as checked - which they are not. I compared the flash end eeprom read by PonyProg and avrdude + usbasp and these were identical. The only difference is when reading BOOTxxx configuration bits.

Can anybody confirm that PonyProg shows BODLEVEL bits checked instead of BOOTxxx bits? I have version:

PonyProg2000 - Serial Device Programmer - mod by RG (v1.0a) Version 2.08c Beta Nov 18 2013

Chupo_cro



Edited 1 time(s). Last edit at 09/29/2017 02:53PM by chupo_cro.

Dear Chupo_cro,

thanks for your report. I have analyzed it and fixed. You are right. The bit labels for BODLEVEL2, BODLEVEL1, BODLEVEL0 from extended fuse byte were swapped with high fuse byte bits BOOTSZ1, BOOTSZ0, BOOTRST. It was my fault. My apologize. I had copied it from AtMega168 and did not see the difference at first sight when I was added it to PonyProg in June of 2012.

I have attached precompiled Windows executable.

Could you please check it?


Yours sincerely
sonix

chupo_cro Wrote:
-------------------------------------------------------
> I've been using PonyProg for years and this is the
> first time I have a problem. I got some Arduino
> Nano (ATmega328p) boards and wanted to backup the
> bootloader before erasing the chip. I was
> surprised when I saw BOOTSZ1, BOOTSZ0 and BOOTRST
> are unchecked (unprogrammed, bit = 1) and the
> bootloader does work!! The bootloader worked even
> after uploading the first .hex meaning the code
> does NOT start at 0x0000 and eventually reaches
> the bootloader. By checking the fuse bits with
> Avrdude and usbasp programmer I got:
> Extended=0x07, High=0xda and Low=0xff meaning
> BOOTRST and BOOTSZ1 *ARE* programmed (checked, bit
> = 0). Then I noticed PonyProg is showing BODLEVEL0
> and BODLEVEL2 as checked - which they are not. I
> compared the flash end eeprom read by PonyProg and
> avrdude + usbasp and these were identical. The
> only difference is when reading BOOTxxx
> configuration bits.
>
> Can anybody confirm that PonyProg shows BODLEVEL
> bits checked instead of BOOTxxx bits? I have
> version:
>
> PonyProg2000 - Serial Device Programmer - mod by
> RG (v1.0a) Version 2.08c Beta Nov 18 2013

sonix Wrote:
-------------------------------------------------------
> Dear Chupo_cro,
>
> thanks for your report. I have analyzed it and
> fixed. You are right. The bit labels for
> BODLEVEL2, BODLEVEL1, BODLEVEL0 from extended fuse
> byte were swapped with high fuse byte bits
> BOOTSZ1, BOOTSZ0, BOOTRST. It was my fault. My
> apologize. I had copied it from AtMega168 and did
> not see the difference at first sight when I was
> added it to PonyProg in June of 2012.
>
> I have attached precompiled Windows executable.
>
> Could you please check it?
>
>
> Yours sincerely
> sonix

Hi,

I have just checked and configuration bits are now as expected :-) Thank you very much for such a quick reply and for solving the problem!! I really love PonyProg and I am still hoping there will be a solution for using it with USB programmers (at full speed) one day.

BTW, it seems this problem was related to swapped labels:
http://www.avrfreaks.net/forum/bootrst-fuse-was-disabled-bootloader-code-executed

Thank you very much once again!
Best regards

Chupo_cro

sonix Wrote:
-------------------------------------------------------
> Dear Chupo_cro,
>
> thanks for your report. I have analyzed it and
> fixed. You are right. The bit labels for
> BODLEVEL2, BODLEVEL1, BODLEVEL0 from extended fuse
> byte were swapped with high fuse byte bits
> BOOTSZ1, BOOTSZ0, BOOTRST. It was my fault. My
> apologize. I had copied it from AtMega168 and did
> not see the difference at first sight when I was
> added it to PonyProg in June of 2012.
>
> I have attached precompiled Windows executable.
>
> Could you please check it?
>
>
> Yours sincerely
> sonix

Hi again,

now almost 3 years since you sent me PonyProg Version 2.08d Beta mod by RG (v1.01h) Sep 29 2017 where you corrected the fuse bytes for ATmega328P I am still using that very version but recently I got some Arduino Nano boards with ATmega328PB microcontrollers which I can't program because of the µC signature.

I saw in these threads:
http://ponyprog.sourceforge.net/phorum/read.php?2,2603
http://ponyprog.sourceforge.net/phorum/read.php?2,2261

you added the signatures for ATmega328P and a few other AVR microcontrollers some years ago and would appreciate if you could now add the signature for the ATmega328PB too.

I just saw there are now new Qt 3.x.x versions of PonyProg which probably do work with ATmega328PB but I really like the look of those old 2.x.x versions. I have one old Windows XP computer with parallel port and with Windows XP running since 2006. and it would be nice if I could still use the old PonyProg which I am used to - I really like the old fuse bytes user interface which as I can see from the screenshot has now changed.

I still haven't tried to install the new Qt version because I am not sure if both the 2.x.x and the 3.x.x versions of PonyProg can be installed in the same time. Can I install the new Qt version without ruining the old PonyProg 2.08d installation?

BTW, I see the source code for the new Qt version is on Gitgub but I haven't seen the source code for PonyProg 2.x.x versions. Are they available too or is PonyProg 2.x.x closed source?

Best regards

Chupo_cro

chupo_cro Wrote:
> I still haven't tried to install the new Qt
> version because I am not sure if both the 2.x.x
> and the 3.x.x versions of PonyProg can be
> installed in the same time. Can I install the new
> Qt version without ruining the old PonyProg 2.08d
> installation?

Give it a try. There is also PonyProg 2.08e, look here
https://github.com/lancos/ponyprog/releases/tag/V2_08e

>
> BTW, I see the source code for the new Qt version
> is on Gitgub but I haven't seen the source code
> for PonyProg 2.x.x versions. Are they available
> too or is PonyProg 2.x.x closed source?

There are all versions on github on different branches.

Cheers,
Claudio

Dear Chupo_cro,

I have recompiled new source files from github with PonyProg 208e and added new signature bytes for recognition of ATmega328PB processors too. So if your atmega has signature bytes 0x1e, 0x95, 0x16 (this bytes are shown by PonyProg if unknown device is detected) it must be now functional without any warning. I do not have this atmega version available therefore I can not test it by myself. Attached is new executable file for windows.

Yours sincerely
sonix


chupo_cro Wrote:
-------------------------------------------------------
> sonix Wrote:
> --------------------------------------------------
> -----
> > Dear Chupo_cro,
> >
> > thanks for your report. I have analyzed it and
> > fixed. You are right. The bit labels for
> > BODLEVEL2, BODLEVEL1, BODLEVEL0 from extended
> fuse
> > byte were swapped with high fuse byte bits
> > BOOTSZ1, BOOTSZ0, BOOTRST. It was my fault. My
> > apologize. I had copied it from AtMega168 and
> did
> > not see the difference at first sight when I
> was
> > added it to PonyProg in June of 2012.
> >
> > I have attached precompiled Windows executable.
> >
> > Could you please check it?
> >
> >
> > Yours sincerely
> > sonix
>
> Hi again,
>
> now almost 3 years since you sent me PonyProg
> Version 2.08d Beta mod by RG (v1.01h) Sep 29 2017
> where you corrected the fuse bytes for ATmega328P
> I am still using that very version but recently I
> got some Arduino Nano boards with ATmega328PB
> microcontrollers which I can't program because of
> the µC signature.
>
> I saw in these threads:
> http://ponyprog.sourceforge.net/phorum/read.php?2,
> 2603
> http://ponyprog.sourceforge.net/phorum/read.php?2,
> 2261
>
> you added the signatures for ATmega328P and a few
> other AVR microcontrollers some years ago and
> would appreciate if you could now add the
> signature for the ATmega328PB too.
>
> I just saw there are now new Qt 3.x.x versions of
> PonyProg which probably do work with ATmega328PB
> but I really like the look of those old 2.x.x
> versions. I have one old Windows XP computer with
> parallel port and with Windows XP running since
> 2006. and it would be nice if I could still use
> the old PonyProg which I am used to - I really
> like the old fuse bytes user interface which as I
> can see from the screenshot has now changed.
>
> I still haven't tried to install the new Qt
> version because I am not sure if both the 2.x.x
> and the 3.x.x versions of PonyProg can be
> installed in the same time. Can I install the new
> Qt version without ruining the old PonyProg 2.08d
> installation?
>
> BTW, I see the source code for the new Qt version
> is on Gitgub but I haven't seen the source code
> for PonyProg 2.x.x versions. Are they available
> too or is PonyProg 2.x.x closed source?
>
> Best regards

lancos Wrote:
-------------------------------------------------------
> Give it a try. There is also PonyProg 2.08e, look
> here
> https://github.com/lancos/ponyprog/releases/tag/V2
> _08e
>
> There are all versions on github on different
> branches.
>
> Cheers,
> Claudio

Hi,

sorry, I saw your reply only last night - I didn't notice it before because for some reason the email notifications weren't on.

Thank you very much for the link. I really can't understand why I couldn't find the source code before when I was searching for it :-/ I think I've found only 3.x.x version sources somewhere (maybe on Sourceforge) but I couldn't find 2.xx versions.

Since I saw ATmega328PB wasn't listed in the description of 2.08e I was about to try to compile the 2.08e and then to try finding out if I could add the ATmega328PB signature but now when I was back here to reply to your message I saw sonix already did that :-))

The source seemed to be a Code::Blocks project so I tried to compile it - I had to update the linker search path with the path to inpout32.dll and now I only have to figure out how to compile v (I tried using mingw32-make but there were errors).

BTW, I saw some new AM4 motherboards have serial and parallel ports. Are these real RS232 ports (with true +/-12 V RS232 voltage levels) and real parallel ports accessible in the way PonyProg accesses the ports?

Thank you for answering me
Best regards

ps
There were some problems with sending the message. I sent the message but there was "Gateway timeout error" and when I tried to send the message again there was a message "The message was already posted, not allowed to send the same message multiple times", but the message didn't show in the forum. Now I am sending one more time.

Chupo_cro

sonix Wrote:
-------------------------------------------------------
> Dear Chupo_cro,
>
> I have recompiled new source files from github
> with PonyProg 208e and added new signature bytes
> for recognition of ATmega328PB processors too. So
> if your atmega has signature bytes 0x1e, 0x95,
> 0x16 (this bytes are shown by PonyProg if unknown
> device is detected) it must be now functional
> without any warning. I do not have this atmega
> version available therefore I can not test it by
> myself. Attached is new executable file for
> windows.
>
> Yours sincerely
> sonix

Hi sonix,

this was really a surprise because I didn't notice Claudio's reply up until the last night and today when I returned here to send him a reply I saw his post isn't the last one. In the first second I thought your old post from a few years ago somehow "jumped" to the bottom but then I realized you replied just in between my last night's visit and now :-))

Thank you very much for enabling programming of ATmega328PB :-) If I understand correctly what you have done this time is - since you don't have the ATmega328PB to read its signature, you added to the list of known devices the signature which has the meaning "unknown device"? Does that mean it is now anymore not possible to get the "unknown device" error? For example, if in the future there will be ATmega328PC or some other ATmega328 microcontroller - PonyProg RG101i will work without adding the new signature?

I will notify you about the results as soon as I chech if it works.

In the meantime, may I ask you for the help with compiling the PonyProg? As I said in my reply to Claudio, I for some reason couldn't find the PonyProg source code until Claudio repied with the link and now that I have it I tried to compile it using Code::Blocks on Windows 10. First I had to remove:

-std=c++ox

because of _stricmp error. Then I had to add path to inpout32.dll to the linker search path and now the last thing would be to compile the v but I got an error:

mingw32-make.exe" -f Makefile.win
'uname' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the path specified.
The system cannot find the path specified.
i686-w64-mingw32-g++ -D_WINDOWS -O2 -fpermissive -Wno-write-strings -Iincludew -c -o objwin/vapp.o srcwin/vapp.cpp
process_begin: CreateProcess(NULL, i686-w64-mingw32-g++ -D_WINDOWS -O2 -fpermissive -Wno-write-strings -Iincludew -c -o objwin/vapp.o srcwin/vapp.cpp, ...) failed.
make (e=2): The system cannot find the file specified.
Makefile.win:176: recipe for target 'objwin/vapp.o' failed
mingw32-make: *** [objwin/vapp.o] Error 2

and how to compile it to get v.dll

uname is Linux command but then Makefile.win is for Windows so I don't know where is the problem. I triend using nmake from Visual Studio but that didn't work either.

BTW, these are ATmega328PB:

https://www.aliexpress.com/item/32828478049.html

You can see the labels when you zoom the pictures, the description is wrong. I ordered these from the same seller before and I got normal ATmega328s but now they changed it with ATmega328PB and I didn't notice it until I tried to program them with PonyProg.

Thank you again
Best regards

Chupo_cro



Edited 1 time(s). Last edit at 11/29/2020 03:13AM by chupo_cro.

Dear Chupo_cro,

compilation with code:blocks is a little bit tricky Firstly you have to setup correctly the C:B project and compile in advance also vlib libraries (for simplification of this process I added already pre-compiled libraries). Below you can see my C:B settings for successful compilation.

I have win7 x64, CodeBlocks 20.03, GNU GCC compiler I have TDM-GCC-32 version 5.1.0 (I do not tested it with different compiler version, but in general it must be OK with newer version too)

So you can try to compile it by yourself. If you face any issues feel free to report it

Good luck.

Yours sincerely
sonix


My C:B project setup:

Copy vlib libraries v1.25 (attached) into v\lib\:
libVdbg.a
libVrel.a


Add source files into code:blocks project (if missing, there is compilation error):
linuxsysfsint.cpp
linuxsysfsint.h

********************************
[PonyProg2000 Compiler settings]
********************************
Other options:
-fpermissive -Wno-deprecated -Wno-write-strings

#Defines:
_WINDOWS


********************************
[Debug Compiler settings]
********************************
#Defines:
vDEBUG


********************************
[PonyProg2000 Linker settings]
********************************
-static-libgcc
-static-libstdc++

OR

********************************
[PonyProg2000 Compiler settings / Compiler flags]
********************************
Static libgcc
Static libstdc++

********************************
[Debug Linker settings]
********************************
Other linker options:
-lVdbg
-linpoutx64
-lmingw32
-lwinmm
-lcomctl32

********************************
[Release Linker settings]
********************************
Other linker options:
-lVrel
-linpoutx64
-lmingw32
-lwinmm
-lcomctl32


********************************
[PonyProg2000 Search directories]
********************************
Compiler:
v\includew

Linker:
.
v\lib
InpOutLib/x64



chupo_cro Wrote:
-------------------------------------------------------
> sonix Wrote:
> --------------------------------------------------
> -----
> > Dear Chupo_cro,
> >
> > I have recompiled new source files from
> github
> > with PonyProg 208e and added new signature
> bytes
> > for recognition of ATmega328PB processors too.
> So
> > if your atmega has signature bytes 0x1e, 0x95,
> > 0x16 (this bytes are shown by PonyProg if
> unknown
> > device is detected) it must be now functional
> > without any warning. I do not have this atmega
> > version available therefore I can not test it
> by
> > myself. Attached is new executable file for
> > windows.
> >
> > Yours sincerely
> > sonix
>
> Hi sonix,
>
> this was really a surprise because I didn't notice
> Claudio's reply up until the last night and today
> when I returned here to send him a reply I saw his
> post isn't the last one. In the first second I
> thought your old post from a few years ago somehow
> "jumped" to the bottom but then I realized you
> replied just in between my last night's visit and
> now :-))
>
> Thank you very much for enabling programming of
> ATmega328PB :-) If I understand correctly what you
> have done this time is - since you don't have the
> ATmega328PB to read its signature, you added to
> the list of known devices the signature which has
> the meaning "unknown device"? Does that mean it is
> now anymore not possible to get the "unknown
> device" error? For example, if in the future there
> will be ATmega328PC or some other ATmega328
> microcontroller - PonyProg RG101i will work
> without adding the new signature?
>
> I will notify you about the results as soon as I
> chech if it works.
>
> In the meantime, may I ask you for the help with
> compiling the PonyProg? As I said in my reply to
> Claudio, I for some reason couldn't find the
> PonyProg source code until Claudio repied with the
> link and now that I have it I tried to compile it
> using Code::Blocks on Windows 10. First I had to
> remove:
>
> -std=c++ox
>
> because of _stricmp error. Then I had to add path
> to inpout32.dll to the linker search path and now
> the last thing would be to compile the v but I got
> an error:
>
> mingw32-make.exe" -f Makefile.win
> 'uname' is not recognized as an internal or
> external command,
> operable program or batch file.
> The system cannot find the path specified.
> The system cannot find the path specified.
> i686-w64-mingw32-g++ -D_WINDOWS -O2 -fpermissive
> -Wno-write-strings -Iincludew -c -o objwin/vapp.o
> srcwin/vapp.cpp
> process_begin: CreateProcess(NULL,
> i686-w64-mingw32-g++ -D_WINDOWS -O2 -fpermissive
> -Wno-write-strings -Iincludew -c -o objwin/vapp.o
> srcwin/vapp.cpp, ...) failed.
> make (e=2): The system cannot find the file
> specified.
> Makefile.win:176: recipe for target
> 'objwin/vapp.o' failed
> mingw32-make: *** Error 2
>
> and how to compile it to get v.dll
>
> uname is Linux command but then Makefile.win is
> for Windows so I don't know where is the problem.
> I triend using nmake from Visual Studio but that
> didn't work either.
>
> BTW, these are ATmega328PB:
>
> https://www.aliexpress.com/item/32828478049.html
>
> You can see the labels when you zoom the pictures,
> the description is wrong. I ordered these from the
> same seller before and I got normal ATmega328s but
> now they changed it with ATmega328PB and I didn't
> notice it until I tried to program them with
> PonyProg.
>
> Thank you again
> Best regards

Dear Chupo_cro,

no, programming within the SAME atmega type (in this case atmega328) is functional even if there is warning about unknown device type so you can continue by clicking on "Ignore" button.

If you add new signature bytes ( this is written in device datasheet in section called mostly "signature bytes" ) in source code and recompile it to new executable it will recognize the CPU as atmega328 without any warning and continue read/write operations. But if you have new type of CPU which is NOT available in device selection you must create it. It means you must define device type, flash/eeprom sizes, define also fuse bytes and its descriptions, add it to device selection menu...

Yours sincerely
sonix


chupo_cro Wrote:
-------------------------------------------------------

> Thank you very much for enabling programming of
> ATmega328PB :-) If I understand correctly what you
> have done this time is - since you don't have the
> ATmega328PB to read its signature, you added to
> the list of known devices the signature which has
> the meaning "unknown device"? Does that mean it is
> now anymore not possible to get the "unknown
> device" error? For example, if in the future there
> will be ATmega328PC or some other ATmega328
> microcontroller - PonyProg RG101i will work
> without adding the new signature?
>



Edited 1 time(s). Last edit at 11/29/2020 08:15PM by sonix.

sonix Wrote:
-------------------------------------------------------
> Dear Chupo_cro,
>
> compilation with code:blocks is a little bit
> tricky Firstly you have to setup correctly the
> C:B project and compile in advance also vlib
> libraries (for simplification of this process I
> added already pre-compiled libraries). Below you
> can see my C:B settings for successful
> compilation.
>
> I have win7 x64, CodeBlocks 20.03, GNU GCC
> compiler I have TDM-GCC-32 version 5.1.0 (I do not
> tested it with different compiler version, but in
> general it must be OK with newer version too)
>
> So you can try to compile it by yourself. If you
> face any issues feel free to report it
>
> Good luck.
>
> Yours sincerely
> sonix

Thank you very much. There was .cbp project file in the source code and when I opened it with Code::Blocks almost everything was already set as in your list of the settings. The only thing I had to do was to add:

InpOutLib\Win32

to the Search path for the linker (I thought I had to use the 32 bit version because the program will run on 32 bit Windows XP but you suggested to add the InpOutLib\x64 - how is it possible the .exe you sent me works well on my 32 bit Windows XP if you linked the program with 64 bit version of InpOutLib .dll?).

And I had to uncheck:

Have g++ follow the comming C++ox (aka c++11) ISO C++ language standard [-std=c++0x]

because of strcasecmp() calling _stricmp()

The only problem seems to be I can not compile the V library neither with mingw32-make nor with nmake and I can't download the attachment you've sent me either. When I click on:

compilled_vlib_v125.zip ( 706.6 KB )

there is "The requested file (id 101) was not found." error.

Do I maybe have to compile the V library by using cygwin?

Chupo_cro

Dear Chupo_cro,

I have created new topic about compilation of PonyProg version 2xx and Vlib with CodeBlocks. Please check it at link below or at the top of message list.

http://ponyprog.sourceforge.net/phorum/read.php?2,2703

P.S:
The .cbp project is already preset for compilation without need to change it. So do not change search directory InpOutLib/x64. Correct Dll is loaded during PonyProg start and it is compiled for usage of both x86 and x64 dll's

Yours sincerely
sonix

chupo_cro Wrote:
-------------------------------------------------------
> sonix Wrote:
> --------------------------------------------------
> -----
> > Dear Chupo_cro,
> >
> > compilation with code:blocks is a little bit
> > tricky Firstly you have to setup correctly
> the
> > C:B project and compile in advance also vlib
> > libraries (for simplification of this process I
> > added already pre-compiled libraries). Below
> you
> > can see my C:B settings for successful
> > compilation.
> >
> > I have win7 x64, CodeBlocks 20.03, GNU GCC
> > compiler I have TDM-GCC-32 version 5.1.0 (I do
> not
> > tested it with different compiler version, but
> in
> > general it must be OK with newer version too)
> >
> > So you can try to compile it by yourself. If
> you
> > face any issues feel free to report it
> >
> > Good luck.
> >
> > Yours sincerely
> > sonix
>
> Thank you very much. There was .cbp project file
> in the source code and when I opened it with
> Code::Blocks almost everything was already set as
> in your list of the settings. The only thing I had
> to do was to add:
>
> InpOutLib\Win32
>
> to the Search path for the linker (I thought I had
> to use the 32 bit version because the program will
> run on 32 bit Windows XP but you suggested to add
> the InpOutLib\x64 - how is it possible the .exe
> you sent me works well on my 32 bit Windows XP if
> you linked the program with 64 bit version of
> InpOutLib .dll?).
>
> And I had to uncheck:
>
> Have g++ follow the comming C++ox (aka c++11) ISO
> C++ language standard [-std=c++0x]
>
> because of strcasecmp() calling _stricmp()
>
> The only problem seems to be I can not compile the
> V library neither with mingw32-make nor with nmake
> and I can't download the attachment you've sent me
> either. When I click on:
>
> compilled_vlib_v125.zip ( 706.6 KB )
>
> there is "The requested file (id 101) was not
> found." error.
>
> Do I maybe have to compile the V library by using
> cygwin?

Dear Chupo_cro,

I have re-uploaded the file. Maybe it has been corrupted during transfer to the server, because I got "504 gateway error" too. Thanks for reporting it

Yours sincerely
sonix

chupo_cro Wrote:
-------------------------------------------------------
> The only problem seems to be I can not compile the
> V library neither with mingw32-make nor with nmake
> and I can't download the attachment you've sent me
> either. When I click on:
>
> compilled_vlib_v125.zip ( 706.6 KB )
>
> there is "The requested file (id 101) was not
> found." error.

sonix Wrote:
-------------------------------------------------------
> Dear Chupo_cro,
>
> no, programming within the SAME atmega type (in
> this case atmega328) is functional even if there
> is warning about unknown device type so you can
> continue by clicking on "Ignore" button.

Aaaaaaa, so I could use PonyProg with ATmega328PB even with the older version by pressing "Ignore" :-)) I did try that back in July but I tried to press "Ignore" when reading the configuration bits but in that case the "Unknown device" shows twice and I didn't realize it would work if I press "Ignore" one more time :-/ Now I tried to use the old version just to see if it will work and it does work.

Of course, I will be using the new version that you send where there isn't "Unknown device" error, thank you again.

I will try to compile the program now that you sent the instructions and the files and will then reply to notify you if it works.

Regards

Chupo_cro



Edited 1 time(s). Last edit at 12/01/2020 12:50AM by chupo_cro.