Skip to main content ↑ ↓

Topics

This section allows you to view all Topics made by this member. Note that you can only see Topics made in areas you currently have access to.

Topics - JimNarem

1
Web platform / using PiratePICprog with web platform
Of course we managed to blow away the boot loader on the web platform.

Not having a real PIC programmer (only AVR and JTAG stuff) I started hacking around with
PiratePICprog.  I added a chip description in pic.c:
Code: [Select]
    {
		.name = "33FJ128GP204",
		.ID = 0x627,
		.flash = 512*256,
		.eeprom = 0,
		.family = FAMILY_24FJxxGAxxx,
	}
and hooked up the bus pirate according to the wiki page for PiratePICprog.  You then run into
the same problem when using pirate-loader on the web platform.  The hex files generated by
mplabx, and the bootloader dp-wp-bootloader.v0a.hex have addresses outside the range
of the flash memory.  For the boot loader, it has:
Code: [Select]
:0200000401F009
:10000000FFFF0000FFFF0000FFFF0000F9FF0000FE
:10001000FFFF00007FFF0000F8FF0000C3000000AA
:10002000FF000000FF000000FF000000FF000000D4
which writes a bunch of config stuff at starting address 0x01f0 0000.  A brief poke at the data sheet
shows that this is a lot like the fuse bits on the AVR.  Deleting this from the HEX file allows
piratePICprog to flash the bootloader and lets us continue development.

In the long run, manually hacking HEX files is not a good thing.  Now, I don't really know enough
about the PIC to understand what the right thing to do here is.  The code that reads HEX files
in piratePICprog does NOT do the right thing here since it assumes that the address space of the
HEX file is contiguous and this out-of-band data is far away from the valid flash addresses.
HEX files generated by mplabx are full of these references to 0x01f0 0000, and they are
scattered within the file (unlike the boot loader where it's at the end).

So my question is:  what's the right thing to fix?
2
Web platform / using pirate-loader with the web platform?
Has anyone hacked up the linux BP tool pirate-loader to upload firmware for the
web platform?  It seems like a vast overkill to install mono just to run the ds30 GUI;
all it's really doing is shoving a HEX file across a serial port.  Clearly pirate-loader
has been hand-hacked specifically for the BP, but isn't the protocol the same?

When pirate-loader is pointed at the web platform and run it says:

Code: [Select]
compute% pirate-loader --dev=/dev/webplatform --hello
+++++++++++++++++++++++++++++++++++++++++++
+ Pirate-Loader for BP with Bootloader v4 +
+++++++++++++++++++++++++++++++++++++++++++

Opening serial device /dev/webplatform...OK
Configuring serial port settings...OK
Sending Hello to the Bootloader...OK

Device ID: UNKNOWN [ab]
Bootloader version: 1,02
Unsupported device (ab:UNKNOWN), only 0xD4 PIC24FJ64GA002 is supported

After a quick look at the pirate-loader.c code, it looks like some careful crafting of the
defines might make it work but I'm an AVR dude and know nothing about PICs.

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.01192282424session_write_close ( )...(null):0
20.01222414016ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.01222414792Database_MySQL->query( ).../DatabaseHandler.php:119
40.05672553528Database_MySQL->error( ).../Db-mysql.class.php:273