Skip to main content ↑ ↓
Topic: Bootloader v4 (ds30 Loader) (Read 57253 times) previous topic - next topic

Re: Bootloader v4 (ds30 Loader)

Reply #60 –
Welcome to the forum Mikael. Thanks, I'll add that, great addition.
Got a question? Please ask in the forum for the fastest answers.

Re: Bootloader v4 (ds30 Loader)

Reply #61 –
Well, the ds loader changes weren't really all that bad. The hardest part was figuring out WHERE to make the changes. Here's a list of changes I made.

•   I fixed a small bug wherein ds loader would crash if an invalid hex file was loaded. I stumbled across it because I needed a hex file to test with while I wasn’t connected to the internet.  At the time, I simply created a text file with a .hex extension. Not something that should happen often, but changing the following line…

 
….to the following code fixes the problem well.

 

•   Not sure if the following line is a good idea. Check what the function does and consider the consequences of hitting this line when turning on/off advanced mode. I’m concerned that if someone goes from advanced mode back to normal mode, it will negatively affect some of the settings. Again, if you check what the code in ResetSettingsToDefault does, you’ll probably be able to determine if this is an actual issue. Or just test it.

 


•   One of  your concerns was that users would accidentally check the Overwrite Bootloader option. As you’ll see in below, the settings.xml file allows you to effectively disable this checkbox from being clicked.  Run this through a couple of scenarios and make sure that this is a valid thing to do. I know it’s not something you asked for, so I might not should have implemented it the way I did.
•   I believe the way I did things, I also eliminated the bug that required you to close the program to make it reparse the file. You’ll have to test it though and let me know.
•   The settings.xml file supports relative paths now, at least when opening the settings.xml file the first time. So you can have BPv3-Firmware-v4.hex for the filename, but when you close the application, ds loader will replace it with the full path to the hex file. I can change how this works to save a relative path instead of the full path, but you’ll have to tell me if that’s necessary.
•   I thought about making it so ds loader would automatically load up all .hex files in the current directory when the application starts, but that would force the application to parse each file that it loads. Seemed a bit overkill so I didn’t do it. Lemme know what you think.
•   I didn’t modify the structure of the VisualStudio solution, but I SO want to. It bugs me how he’s got the directory structure laid out and that the ghelper.dll isn’t included with it.
•   Though the new DefaultStartSettings will correctly allow automatic configuration of the custom boot loader placement, I do not know if those settings will be applied if the Advanced Mode is not turned on. As I have implemented these features, the Advanced Mode remains off if it was already off when you load a new file. I didn't look far enough into the code to find out.
•   You might want to let the original author of ds loader take a look at the changes I made for final approval. I didn’t exactly follow all of the coding conventions he used, but my code is very clean. In any case, now that there are 2-3 people working in the ds loader code, it really needs to go in some kind of source control. Passing code around like this is a bad idea.
•   Here are the settings currently supported by the settings.xml file.

 

  false
  false
  true
  343
  459
  BPv3-Firmware-v4.hex
 
    115200
    PIC24FJ
    64GA002
    true
    1
    true
    true
 



I’m fairly familiar with the ds loader code now so I’m comfortable making additional changes as needed.

If all goes well, you'll find a link to download the modified code and compiled assemblies at:

http://www.box.net/shared/v0sfrgeisu

Re: Bootloader v4 (ds30 Loader)

Reply #62 –
Fantastic work Alex, thank you!

The advanced settings reset is a concern. I can see it either way: preserving advanced settings to avoid unintended errors, or resetting because they aren't visible any more. My primary concern is: will the advanced settings stick when the user starts the programmer for the first time, the rest I can leave to Mikael. I'll do some testing on this.

Thanks for the overwrite bootloader switch, that's a great addition. Between that and the built-in bootloader protection it should be as close to fool-proof as we can get.

Accepting a relative path on first startup is perfect. After that the recentfileX.xml will be used instead, which should include the correct full-path for the user's system.

Let's not parse all the files for now, the relative path on first load is everything I wanted an more :)

I'll do some testing with startup and advanced mode, and wait to hear what Mikael has to say.

I added the original source archive to the Bus Pirate SVN, then copied your source archive over it and created a patch. This code does not contain the bootloader protection function that Mikael posted a few posts back. Here's the SVN and patch:
http://code.google.com/p/the-bus-pirate ... 0%20Loader

I also talked to Mikael about SVN today, so hopefully there's an official ds30Loader SVN soon. For now, I can add everyone to the Bus Pirate project if you send me a google registered email address.

I'll test Sjaak's updater now.
Got a question? Please ask in the forum for the fastest answers.

Re: Bootloader v4 (ds30 Loader)

Reply #63 –
Sorry, google didn't like the space in that link. This should get you close:
http://code.google.com/p/the-bus-pirate ... tloader-v4
Got a question? Please ask in the forum for the fastest answers.

Re: Bootloader v4 (ds30 Loader)

Reply #64 –
Ian, I hope you understand what i did wrote ;) I tried to add as much comments (normally not my style ;))

The byte order for the firmware.h should be the same order as the loader sends them. If it is convienant it could be changed easily (to support an auto-build process).

Re: Bootloader v4 (ds30 Loader)

Reply #65 –
A few comments on the installer:
It should probably be under GPL. The ds30Loader code is GPL so that 'infects' the other code with GPL as well. The Bus Pirate is public domain (free for any use) with the idea that you can prototype with the Bus Pirate, then take the protocol source code and implement it in you own project without any licensing restriction whatsoever. The installer isn't part of that, so I have no problem with it being GPL.

I started writing about erasing the next-to-last page, but I think I found an issue in how I used the bootloader. The user jump instruction for the new bootloader goes in the last two instrucitons of the next-to-last page. The firmware includes 0xff0000 NOP instead of the 0xffffff NOP.

The ds30 Loader firmware has a timeout delay instead of the jumpered pins method used on the Bus Pirate. I just set the delay to 1ms instead of eliminating it. In all my testing everything works fine, but I'm not sure why really.

The jumper between the pins allows the bootloader to start (else it jumps), then it trys to get a byte from the UART for the delay period (i set it to 1ms), if it's not a hello, it exits to the user code. If the chip is blank, these are NOPs that walk back to the bootloader (thus the installer must erase the next-to-last page too). If there is a user program, then the instructions are a branch to the location where it starts. Right now I have no problems entering and using the bootloader on a programmed chip, but I don't know why. It should time out and quit to the existing firmware after a short period if that instruction is already programmed! That might explain a painful debugging experience I had last week. I need to just remove the timeout, it's of no use to us with the jumper.

The point is: erase the next to last page so it returns to the bootloader on an upgraded chip, instead of whatever random instruction happens to be already programmed.

Also: do you have a way to turn a .hex into byte code like that? Maybe MPLAB already outputs it but I'm unaware. IF not, it shouldn't be too difficult to write a PERL script to do it.
Got a question? Please ask in the forum for the fastest answers.

Re: Bootloader v4 (ds30 Loader)

Reply #66 –
Ah, I remember. If it times out then the chip resets:

        mov    #__SP_init, WSTPTR   ;reinitialize the Stack Pointer

We need to keep that for upgrades with the existing bootloader (you can activate it whenever on a blank chip).
Got a question? Please ask in the forum for the fastest answers.

Re: Bootloader v4 (ds30 Loader)

Reply #67 –
I could rewrite it so it is my 'own' code. The it should be ok to release it under the same license as the buspirate? It is all documented on microchip.com. I dunno if a couple of asmcodes BTW are covered/infected by the gpl.

Ferase(0xA000); should erase the second last page. I indeed forget the two instructions before the loader. I looked at the current code and the jump to userapp is located just before start??

I think the delay should stay as it is also used as communicationstimeout.

I'll try to come up with a script to export a .hex to the needed include.

Re: Bootloader v4 (ds30 Loader)

Reply #68 –
ian: that line doesn't reset the device, it just resets the stack pointer. If we would reset after comm. timeout, we would NEVER get to the user application.

nice job alex!
1. Great you found it, I solved it slightly differently, setting objHex to null if parse failed in DoParse(). I also added some code in repaint to draw a cross if objhex=null.
2. As Ian wrote, settings are reseted because they're not visible.
3. (There's also the pic side protection)
4. I think that was already fixed in the version you got. Check leave events of the textboxes
5. -
6. Fixed what I think is a better structure with a single solution. But the ghelper won't go in it.
7. The settings will be applied.
8. I'm working on a svn server, test it here:
https://mrmackey.no-ip.org:444/svn/ds30 ... k/pc-side/
l: guest
p: G
9. -

Re: Bootloader v4 (ds30 Loader)

Reply #69 –
The svn server worked.

Here's a sequence of events that explains my concern about advanced mode:
1. I start ds loader. It is in normal mode by default.
2. I go to Advanced Mode and make changes there such as enabling the custom boot loader placement.
3. I turn off Advanced mode.
4. I apply the hex to the pic.

From what I can tell, once you go into Advanced mode and make changes, you have to apply the hex while in advanced mode, or you'll lose your settings. I haven't tested any of this on my BP though, so I'm not sure.

Dll files can be added to a VS solution by way of "Solution Folders".... See below for an example of how I usually do this. I added the ghelper.dll to a folder called "ReferencedAssemblies.

http://www.box.net/shared/yeuvx6l3cv

Re: Bootloader v4 (ds30 Loader)

Reply #70 –
looks like I made some huge mistakes in my code :S The problem was a bad testpattern (not suitable  for testing bleh!). I now used a .hex of the 217 svn and i noticed the error and (I think) I corrected it.

Anyway I included it (the bootloader of svn217') in the firmware.h.. I Also included an .html file (sorry no perl on this windows box) which convert the bootloader to an array which can be used in firmware.h. Select the start and up to the last full 16 byte line.

first line to be selected:
Code: [Select]
:105000002F8C20004227A9004507A90042A7AE0027

last line to be selected:
Code: [Select]
:1057E000FFFFFF00FFFFFF00FFFFFF00FFFFFF00C5

The .html should automagicly add the last 4 word together with the fuses. The .html also handles the byte to 'program word' conversion. I didn't saw a way to use objdump to dump the relevant parts...

As far as I know this attached package should now behave as expected, but I couldn't test it in real (stil haven't got a pic programmer). I also changed the commented out section to be correct byte to 'programword' conversion. 

So Ian, could you please please test it? :p please alter the fwlocation to 0xA800 and uncoment the section in main.c

If it works correctly I'll rewrite the flash.s to comply with the creative 0 license (hadn't the time for it tonight!)

Re: Bootloader v4 (ds30 Loader)

Reply #71 –
Great job, I made a few tweeks to the installer and it works! I uploaded installer with the old bootloader, ran the install, then uploaded the v4 firmware with the ds30 Loader GUI.

Nice thinking on the javascript converter too. I do that a lot, Javascript is one language everyone has an interpreter for, and it's ready to be deployed on the web with no fuss!

I put the installer into the SVN:
http://code.google.com/p/the-bus-pirate ... 4/upgrader

If you give me a google code registered email I can give you commit permission to submit your changes directly to the SVN.

Changes:
I added a DEBUG define. If enabled it uses the 0x9000 write location and skips the jump instruction erase/write.

I added a repeating warning. Any key brings up the user message, 'Y' continues, you're then prompted to press Y again if you're sure. Any other key sends it back to the main user message.

The jump instruction needs to have the second instruction as 0x0000, so I zeroed these three bytes in the jump instruction row write.

I added message to upload v4+ firmware to complete the upgrade.
Got a question? Please ask in the forum for the fastest answers.

Re: Bootloader v4 (ds30 Loader)

Reply #72 –
I also though of entering 'yes' or 'I agree' instead of hitting enter twice for the final version. I'm not satisfied with the javascript tool but I had to :) I think it is not suitable for auto-building.. But it did the job ;)

Good additions, although the debug define could be left out, but on the other hand why not..

I try to register an email with google code later on. (Shall i also add the other changes (other topic) in the trunk? :P)

Re: Bootloader v4 (ds30 Loader)

Reply #73 –
Please hold off on the other changes because we need to make room for them with the new bootloader first. We should but those in a v4 branch that's compatible with the new bootloader.
Got a question? Please ask in the forum for the fastest answers.

Re: Bootloader v4 (ds30 Loader)

Reply #74 –
What do you BTW mean with serial comma's?

I'm not a native speaker :( and my english is prolly better then your dutch :P

Ok. I'll wait for the next release. How many room is there left for new code (using the new bootloader)?