Skip to main content ↑ ↓
Topic: A little development automation tip (Read 5385 times) previous topic - next topic

A little development automation tip

Hopefully this will be useful to some, and not clutter the forum...

I have automated these steps in the development process (shaves off a couple of seconds):
1. Truncate target program image hex file to prevent overwriting bootloader during programming.
2. Command BP to enter "wait for bootloader client" mode.

I specify a batch file as the MPLAB Custom Build Post-Build Step as follows:
"fullabsolutepathtoPostBuild.bat"


Edit: The Post-Build Step quotes kept disappearing (!) when reopening the workspace, so I edited the .mcp file and enclosed the command with double quotes. Seems to work.


The contents of PostBuild.bat is:
Code: [Select]
@echo off
echo Cropping hex file to avoid overwriting bootloader...
srec_cat busPirate.hex -Intel -crop 0 0x14ff8 -Output cropped.hex -Intel

echo Commanding BP to wait for bootloader client...
copy "fullabsolutepathtoWaitBootLoader.txt" \.com10:
Note that the Post-Build Step is executed in the project's Output directory.

The contents of WaitBootLoader.txt is:
Code: [Select]
$ryr
where r = 0x0d

The utility srec_cat is from http://http://srecord.sourceforge.net/

In use, I just hit the BP reset switch (I added one), build the project, press the ds30 Download button, then reset the BP again.

Enjoy.

Re: A little development automation tip

Reply #1 –
Great tip, thank you so much. I bookmarked this because I will use it all the time for most of our projects :)

Are you doing any interesting development on the Bus Pirate?
Got a question? Please ask in the forum for the fastest answers.

Re: A little development automation tip

Reply #2 –
Thanks for the sourceforge link.  I had some ideas for a utility to combine images (e.g. bootloader plus firmware), but I didn't want to create a whole new project.

Re: A little development automation tip

Reply #3 –
@ian,

Glad you found it useful.

Now that I have the Bus Pirate Logic Analyzer "upgrade" under my skin, I am doing that--s l o w l y.

OT: I put my new OLS to use today measuring read access duration of the EPROMs in my old EPROM burner, so I could "size" new ones to burn with copies of the burner EPROMs before their bits leak out, thus rendering the burner useless.


@rsdio,
Isn't open source great! I started to write my own cropper/excluder by modding an old utility I wrote, but I kept thinking--as it took more and more time--that "someone must have already done this..."

Re: A little development automation tip

Reply #4 –
[quote author="flubberlab"]OT: I put my new OLS to use today measuring read access duration of the EPROMs in my old EPROM burner, so I could "size" new ones to burn with copies of the burner EPROMs before their bits leak out, thus rendering the burner useless.[/quote]
Don't you have the source to your EPROM burner firmware?  (that's a trick question, because I wrote my own Apple ][ software to run faster than the provided EPROM burner software that came with the card, and so I can compile it again if any EPROMs lose their bits)

Quote
@rsdio,
Isn't open source great! I started to write my own cropper/excluder by modding an old utility I wrote, but I kept thinking--as it took more and more time--that "someone must have already done this..."
This also happens outside the open source world, provided the community is large enough.  I bought an iPhone because I have decades of Cocoa experience and thought that it would be handy to have a phone that I already knew how to program.  So far, though, every time I have an idea for an iOS application that I would find useful, a quick search of the iPhone Store shows that there's a free version available.  Kinda puts an unexpected hurdle between me and my goal of learning ARM programming, since I still haven't found a project to bite into...

Re: A little development automation tip

Reply #5 –
Edit: The Post-Build Step quotes kept disappearing (!) when reopening the workspace, so I edited the .mcp file and enclosed the command with double quotes. Seems to work.

[OT] Re: A little development automation tip

Reply #6 –
[quote author="rsdio"]
...so I can compile it again if any EPROMs lose their bits)
[/quote]

Thanks for helping to put some meat into this thread!!!

My burner has EPROMs in it, so I need to refresh them before they go... Trick question: How did I read the burner's EPROMs? With some fancy wiring and fast switches--not.

Re: [OT] Re: A little development automation tip

Reply #7 –
[quote author="flubberlab"][quote author="rsdio"]
...so I can compile it again if any EPROMs lose their bits)
[/quote]

Thanks for helping to put some meat into this thread!!!

My burner has EPROMs in it, so I need to refresh them before they go... Trick question: How did I read the burner's EPROMs? With some fancy wiring and fast switches--not.[/quote]
I'm showing my age, because the EEPROM burner that I referred to was designed before surface mount, when everything was in a socket, and EEPROMs were parallel address and parallel data.  I also have an Apple ][, which has a could of spare EPROM sockets if you're not using Basic (and I never used Basic much, anyway).  One trick I would do is to put an EPROM into the Basic socket, and then I could save a binary file to disk.  Then, I could replace the EPROM in the burner card and load the image of its own EPROM to burn into another EPROM.  Without this trick, you'd actually need two identical EPROM burner cards in order to duplicate one.

These days, EPROMs are not in sockets, and they're serial instead of parallel, but thankfully we have the Bus Pirate to 'sniff' serial memory accesses.  With some clever connections, you could actually use the OLS to 'sniff' the contents of a parallel EEPROM, e.g., with 8-bit data and 24-bit address, or 16-bit each.  The catch with either approach is that you have to exercise all subroutines in the code if you want to read the entire EEPROM in situ.

For someone who has a lot of time on their hands, you could create a nice Hollywood 'hacker' effect by mapping the entire EEPROM contents to the screen.  At first, all memory cells would be unknown, and thus black or blank.  But as each unique address is accessed and the 'sniffer' finds the data contents at that location, the screen could be updated with either a simple white dot or perhaps even a color to represent the actual data (so long as the color is offset to be high-contrast against the default, unknown black pixels or characters).  No only would this look cool (for the kind of folks who are easily impressed by Hollywood depictions of technology), but it would also give you an instant map of how much of the EEPROM you've been successful in scanning.  If there are gaps, you could execute new subroutines or features until the gaps are filled in.

I almost wish that I needed something like this...  It'd be so cool to see.

Re: A little development automation tip

Reply #8 –
Well, since the ICD2 takes "so" long to program, I was hoping to use the bootloader to program, and the ICD for just debugging. But that does not appear to work; it appears that MPLAB cannot enter debug mode (Run) unless it does the programming itself. Foiled again...

[OT] Re: A little development automation tip

Reply #9 –
@rsdio,

Interesting ideas.

As you used your spare socket on your Apple ][, I used a homebrew ISA bus sound card on which I had designed a standalone EPROM for a built-in audio sample.

Re: A little development automation tip

Reply #10 –
Quote
it appears that MPLAB cannot enter debug mode (Run) unless it does the programming itself. Foiled again...

Yeah, it needs to use a special debug executive, and memory map to accommodate it. The debug compiles are quite a bit different than the release compiles.

You CAN directly program and/or debug a firmware that uses a bootloader (like the OLS, IR Toy, Bus Pirate, etc) if the firmware is A) located at the beginning of the program space with the reset vector, or B) the firmware includes remapped vectors to jump from start to the main firmware.

BPv3 is A
Ir Toy, OLS, etc, are B - they have extra jump instructions so they will work when programmed without a bootloader or are compiled for debug

You probably already know this since you schooled me on the automation :) I just wanted to share incase.
Got a question? Please ask in the forum for the fastest answers.

Re: A little development automation tip

Reply #11 –
[quote author="flubberlab"]Edit: The Post-Build Step quotes kept disappearing (!) when reopening the workspace, so I edited the .mcp file and enclosed the command with double quotes. Seems to work.[/quote]

Nope. Foiled again. MPLAB eats the outermost pair of quotes each session, so it always converges to zero.

I reported this to Microchip.