RetroBSD

2.11BSD operating system for microcontrollers
It is currently Tue Sep 25, 2018 5:35 pm

All times are UTC




Post new topic Reply to topic  [ 182 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next
Author Message
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:44 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
hi

majenko wrote:
Yes. You send 4 bytes, those same 4 bytes are returned in the same order. If they match what you sent then you know the baud rate is about to be changed and you should change yours as well.


do you have an example of what the current firmware responds with?
(that that does not support this feature).

bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:45 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
I can get one when I get back to my computer.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:53 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
My Uno32 (not supporting it) does this:
Code:
$ ./pic32prog -d /dev/ttyUSB1 -B 2000000 -DDD
Programmer for Microchip PIC32 microcontrollers, Version 2.2.0-wheezy
    Copyright: (C) 2011-2015 Serge Vakulenko
send [7] 1b-1-0-1-e-1-14
 got [17] 1b-1-0-b-e-1-0-8-53-54-4b-35-30-30-5f-32-2
stk-probe: OK
send [11] 1b-2-0-5-e-48-80-84-1e-0-40  <<== Request baud change
 got [8] 1b-2-0-2-e-48-0-5d  <<== Not implemented
    Baud rate: 115200 bps
... etc ...

My SDZL, supporting it, does this:
Code:
$ ./pic32prog -d /dev/ttyUSB1 -B 2000000 -DDD
Programmer for Microchip PIC32 microcontrollers, Version 2.2.0-wheezy
    Copyright: (C) 2011-2015 Serge Vakulenko
send [7] 1b-1-0-1-e-1-14
 got [17] 1b-1-0-b-e-1-0-8-53-54-4b-35-30-30-5f-32-2
stk-probe: OK
send [11] 1b-2-0-5-e-48-80-84-1e-0-40  <<== Request baud change
 got [12] 1b-2-0-6-e-48-0-80-84-1e-0-43  <<== Baud change accepted, will change after response sent.
    Baud rate: 2000000 bps
... etc ...

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 6:39 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
a little bit off the topic - It would be great to have a simple way how to change bootloader's clock setting. Especially on SDZL. Like #define MCU_CLOCK 40000 or something like that as a build param..

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 6:59 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
hi

Pito wrote:
a little bit off the topic - It would be great to have a simple way how to change bootloader's clock setting. Especially on SDZL. Like #define MCU_CLOCK 40000 or something like that as a build param..


the trouble is the clock value doesn't reflect the config word set up
necessary to achieve the speed. I didn't look at MZ but imagine
it uses a similar config arrangement.

if you look in BoardConfig.h for the chipkit loader you can see some
examples.

i suppose it may be possible to create a config word clock generator
pre-processor, but you are on your own with that one.

bye :-)


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Fri Mar 20, 2015 11:37 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
lo

i have ported my stk500v2 application to STM32

this gives a massive speed boost over the AVR solution.

Code:
> pic32prog -S -d /dev/ttyACM0 ~/MICROMITE/MX150\ 28-pin.hex
Programmer for Microchip PIC32 microcontrollers, Version 1.119M
    Copyright: (C) 2011-2014 Serge Vakulenko
      Adapter: STK500v2 Bootloader
 Program area: 1d000000-1d07ffff
    Processor: Bootloader
 Flash memory: 512 kbytes
  Boot memory: 12 kbytes
         Data: 134144 bytes
        Erase: done
Program flash: #################################################### done
 Program boot: #### done     
Rate: 27704 bytes per second
Time: 0:06.19s


so far only programming is working and verify is not supported yet.

the device used for development is one of these:
http://www.ebay.com/sch/Assemblies-EM-Devices-/36322/i.html?_sop=15&_from=R40|R40&ghostText=&_nkw=STM32F103C8T6

these are more expensive than the AVR but not by much. there is also
a maple mini clone device which can be supported at a later time.

i will probably document this next week when verify is working.

bye-bye

EDIT: verify now works as well.


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sat Mar 21, 2015 12:04 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
Hi :-)

This port has been completed and simple documentation is now
available here:
http://wiki.kewl.org/dokuwiki/projects:mork

This example back-end for pic32prog is simpler and better than
the previous example and I imagine it's one the fastest programmers
for pic32prog as well. I have no benchmarks to compare against
though.

My next port will be for the Maple mini clone which has 128 KB flash.
I may be able to support dsPIC/PIC24 programming there, we shall
see.

Bye-bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Wed Mar 25, 2015 9:16 am 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
Lo

To conclude this saga, I now have produced a solution where PIC32MX
controllers can become programmers and hence reproduce and spawn PIC32MX
programmers ad infinitum

http://wiki.kewl.org/dokuwiki/projects:mindy

If you have an SDXL or chipKIT Pi you can test this now. It loads via
the standard boot loader.

The SDXL is pretty fast, but alas, I tested the STM32 F4 discovery and
that's even faster but we will ignore that.

Bye bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Wed Mar 25, 2015 9:23 am 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Nice one. I could really do with having that functionality on my little UltraNano board - PIC32MX250F128B.

What would also be nice is being able to (somehow) switch to a USB UART passthrough mode, so you can also use it as a serial interface. Kind of like you can with the pickit2 where you use pk2ser to connect through it to a serial port.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Wed Mar 25, 2015 9:33 am 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
hi

majenko wrote:
Nice one. I could really do with having that functionality on my little UltraNano board - PIC32MX250F128B.


Tell me the pins and I will create the target. I need something like BoardConfig really, but that
can wait.

Quote:
What would also be nice is being able to (somehow) switch to a USB UART passthrough mode, so you can also use it as a serial interface. Kind of like you can with the pickit2 where you use pk2ser to connect through it to a serial port.


This would be complicated at the moment because this is set up to use polled mode
and the code is identical on STM32 and PIC32. I am also considering merging the
repositories.

I will think about it but this adds complications that I don't need but it could be useful.

Thx. Bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sun May 03, 2015 1:04 pm 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
nroff-man/darron: i've been out of the loop for a few months (some health issues) but things are now coming right. i was wondering if you could possibly add to your page at http://wiki.kewl.org/dokuwiki/projects:nanu-nanu pre-compiled copies of the binaries for upload to the nano? this would (i believe) mean that one would just need a copy of avrdude to do the uploading.

also, a question: why are there three versions? i can understand the 8MHz versus 16MHz difference, but not the 3v3 versus 5v. what code differences are there that are supply voltage dependant?

cheers,
rob :-)

addendum: reading more, i now see that the 3v3 vs 5v difference is in the configuration of the output pins (source versus sink).


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Fri May 08, 2015 8:40 am 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
Good day. I am glad to read that you are well again.

robert.rozee wrote:
nroff-man/darron: i've been out of the loop for a few months (some health issues) but things are now coming right. i was wondering if you could possibly add to your page at http://wiki.kewl.org/dokuwiki/projects:nanu-nanu pre-compiled copies of the binaries for upload to the nano? this would (i believe) mean that one would just need a copy of avrdude to do the uploading.


I don't create pre-compiled hex versions because they would include proprietary firmware, otherwise known as the program executive, being distributed without any license to do so.

You can look as much as you like, but MCHP don't explicitly allow redistribution of their firmware.

The build process itself will pull in the blobs using wget.

Quote:
also, a question: why are there three versions? i can understand the 8MHz versus 16MHz difference, but not the 3v3 versus 5v. what code differences are there that are supply voltage dependant?

cheers,
rob :-)

addendum: reading more, i now see that the 3v3 vs 5v difference is in the configuration of the output pins (source versus sink).


The best solution, I found, is the unsupported one, which is 3V3 16M. This isn't supported by ATMEL but it probably work more often than not. You can verify the firmware after programming to relieve anxiety.

However, a better solution overall is using a MAPLE MINI clone which are not much more expensive yet much faster. Also, although the project page doesn't mention it (MORK for STM32) there is a target for the STM32 F4 discovery and this board is the fastest solution but requires two USB cables (one for power and one for communications).

Bye bye.


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sun May 31, 2015 6:02 pm 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
the PE not being redistributable is certainly a bit of a problem. it also appears your code may have the target PIC parameters hardcoded, which means a recompile and firmware upload whenever a new device type is added.

however, inspired by your work with the nano, i've created a similar (simpler) version that uses a derivative of my 'ascii JTAG' protocol, now called 'ascii ICSP'. i've also (poorly) updated the bitbang.c code for pic32prog to create a complete working system, posted here:
http://www.thebackshed.com/forum/forum_posts.asp?TID=7686&PN=1

the 'ascii ICSP' protocol contains a few extra extensions that should allow it to be used to program other lower-end PIC families that support a PGC/PGD interface. there are extensions to control an external MCLR switching transistor and turn on/off a Vpp supply, as well as a command ('@') to read back 6 of the nano's analog inputs.


cheers,
rob :-)


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Jun 01, 2015 12:56 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
hi

you can recompile the code with the PE disabled if you really want to.
look in the source code.

without PE enabled writing takes about 10 times longer.
i don't remember the exact figure.

you are right about the device ids being hard coded, but more often
than not microchip also change the algorithm when releasing new devices.

for example, micromips is on the horizon, nothing can be tested yet and
the current algorithm will not work.

bye

EDIT:
PS. PIC32MM micromips was documented in 60001145P.pdf but some time
after publishing this document Microchip removed it from their web server. It
would seem to have been released in error. You may find it somewhere else.


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Tue Jun 02, 2015 4:50 am 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
nroff-man wrote:
for example, micromips is on the horizon, nothing can be tested yet and
the current algorithm will not work.


all the more reason to keep the programming algorithm contained within pic32prog, and have the programmer as minimal as is possible. the implementation of 'ascii JTAG' just knows about the two pins (PGC and PGD) and how to manipulate them. the methods used are generic enough to allow for just about any programming algorithm upstream.

of course, the down side of this approach is slower programming speed, but not enormously so. i've been able to achieve 4 minutes to transfer 256k, which is pretty acceptable for the hobbyist environment. in a production environment this would be far too slow, but then that is not the environment i am aiming for.

i would be most thankful for anyone who could have a look at the sources i've posted over on the backshed forums and comment. while i've tested it all myself, i would like to know how what i've produced performs for others.


cheers,
rob :-)


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Tue Jun 02, 2015 2:55 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
hi

algorithms needs writing whether in the chip or on the host computer.

i doubt if there are many (if any) people who even bother with the
high speed solutions I already created, and you would be better off
using the Maple Mini clone for speed, and I imagine that nobody
will ever want to use a slower solution for any reason whatsoever.

there really is little point doing this

bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sat Jun 06, 2015 12:29 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Any chance of a chip erase option to pic32prog? One of my "associates" managed to lock themselves out of a board by enabling CP and now can't do anything with it until they have erased the whole chip, and all they have is a PICkit2 that doesn't want to work in MPLAB-X.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sat Jun 06, 2015 12:41 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Actually, scratch that request, I just implemented it ;)

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sat Jun 06, 2015 1:25 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Actually no, it's not implemented :(

Can't get a target because the chip is locked, so can't erase the chip to unlock it.

In adapter_t *adapter_open_pickit (void):
Code:
    if (! (a->reply[1] & MCHP_STATUS_CPS)) {
        fprintf (stderr, "Device is code protected and must be erased first.\n");
        pickit_finish (a, 0);
        return 0;
    }

So all attempts to get an adapter in order to erase the CP'd chip fail miserably because it's CP'd. That "locked" message needs moving out of the adapter probe routine and into any routines that would fail because of it. Having it global like that is silly.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sat Jun 06, 2015 4:00 pm 

Joined: Tue Sep 16, 2014 12:51 pm
Posts: 47
Location: christchurch, new zealand
'blindly' sending the ICSP entry sequence along with erase commands is relatively simple, which is how i was erasing a PIC32 a while back when JTAG access was locked out. you should be able to program up any small microcontroller to do this (just manipulation of PGC and PGD).

but i've not needed to use this since switching to using ICSP. although, i've tinkered with the pic32prog source code (in adapter-bitbang.c) quite a bit to bring the command sequences into line with the microchip datasheets.

this is the micromite (BASIC) code i was using:
Code:
Pin(25) = 0            ' PGD (data)   --> pin 4 on target
Pin(24) = 0            ' PGC (clock)  --> pin 5 on target
SetPin 25, DOUT
SetPin 24, DOUT

Pin(2) = 0             ' hold in reset
Pin(7) = 0             ' remove power
Pause 100
Pin(7) = 1             ' reapply power

Pulse 2, 0.200         ' pulse MCLR high for 200uS
For I = 1 To 32        ' send "MCHP" signature
  Read D
  Pin(25) = D
  Pulse 24, 0.005
Next I
Pin(2) = 1             ' release reset
Pause 100

Read D                 ' send "erase chip" command sequence
Do
  Pin(25) = D \ 2      ' TDI
  Pulse 24, 0.005
  Pin(25) = D And 1    ' TMS
  Pulse 24, 0.005
  SetPin 25, DIN
  Pulse 24, 0.005      ' TDO (ignored)
  Pulse 24, 0.005
  SetPin 25, DOUT
  Read D
  If D = 9 Then Pause 100: Read D
Loop Until (D = 99)

Pause 400              ' in theory, target is now unlocked
Pin(7) = 0             ' remove power from target
Pause 100
Pin(7) = 1             ' reapply power, see if still alive
SetPin 25, OFF
SetPin 24, OFF
Restore
GoTo start


Data 0,1,0,0, 1,1,0,1,  0,1,0,0, 0,0,1,1
Data 0,1,0,0, 1,0,0,0,  0,1,0,1, 0,0,0,0       ' "MCHP"

Data 1,1,1,1,1,0,                       9      ' run_test/idle

Data 1,  1,0,0,  0,0,2,0,1,        1,0         ' TAP_SW_MTAP
Data 1,  1,0,0,  2,2,2,0,1,        1,0         ' MTAP_COMMAND
Data     1,0,0,  0,0,2,2,2,2,2,3,  1,0, 9      ' MCHP_ERASE

Data     1,0,0,  0,0,0,0,0,0,0,1,  1,0         ' MCHP_STATUS

Data 99


cheers,
rob :-)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 182 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10  Next

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission