Using SDCC with P-Star

Support Other Pololu products
1

I’m attempting to build a project for the P-Star using SDCC and the related gputils. The first roadblock seems to be that --code-loc 0x2000 has no effect on the compiled output, where it should locate the code as needed for the bootloader. I think the root of this problem is probably on the SDCC end.

My workaround for the above issue is to modify the default gputil linker script for the 25k50 to start the code page at 0x2000 rather than 0x00. This seems like it gets something written to 0x2000, since the P-Star stops automatically going into the bootloader. However, it does not appear to actually run the program.

main.c, some relevant hardware description, and the generated hex file.

UPDATE

Got it working… It appears that the delay1mtcy() function from <delay.h> in the sdcc library breaks something. I’m still not sure what. It doesn’t appear to be busting the stack (nor should it), but I’m not sure how it’s managing to reset the devices I/O.

I’ll post up a working project soon, in case anyone else wants to get SDCC working.

2

For small programs, SDCC will generate the start location at the page start (0x2000 with modified linker script). However, I’ve had trouble with some functions being compiled in which cause the main() to be pushed away from the page start. I’m not sure why at this point. It seems that delay1mtcy() also does this.

Additionally, ISR functions will complete ignore the modified linker and be placed at 0x8 and 0x18 instead of 0x2008 and 0x2018.

Here’s an example of a program that works on the P-Star:

#define __SDCC_PIC18F25K50
#define _XTAL_FREQ 48000000

#include <pic18fregs.h>
#include <delay.h>

void delay10x100k(unsigned char x) {
	for(unsigned char t = x; t > 0; t--) {
		delay10ktcy(1);
	}
}

void main()
{
	INTCONbits.GIE = 0;
	T0CON = 0;
	ANSELA = 0; //Turn off all analog channels. 0x0F is all off.
	ANSELB = 0;
	ANSELC = 0;
	TRISA = 0x02; // A1 is input
	TRISB = 0x0;
	TRISC = 0x0;
	LATC = 0x0;

	LATCbits.LATC6 = 0;
	delay10x100k(10);
	LATCbits.LATC6 = 1;

	while(1)
	{
		LATCbits.LATC7 = 0;
		delay10x100k(5);
		LATCbits.LATC7 = 1;
		delay10x100k(5);
	}
}

That would be compiled with sdcc --use-non-free -mpic16 -ppic18f25k50 main.c (SDCC snapshot linux binaries for 2017-12-16, and current or snapshot gputils), with linker script modified as per the gist in the last post. The generated hex can be loaded with p-load -w main.hex and the program seems to run correctly.

3

Hello.

I looked at your HEX file, and it appears that your compiler placed a goto 0x20d4 instruction at address 0, but the P-Star’s bootloader starts executing code at 0x2000, not 0x20d4. The code from 0x2000 to 0x20d4 looks like it could be an SDCC delay routine.

You should try to get the compiler to place the reset and interrupt vectors at their correct locations (0x2000, 0x2008, 0x2018). I am not familiar with the SDCC PIC18 support so I am not sure how to do that. Where did you find the linker script that you modified?

–David

4

The linker script comes from gputils, I just modified the program page line.

I’m not sure why the programs aren’t being compiled to the correct code addresses. I looked at an older project from a couple years ago which I was working on (targeting an 18f4620), and the .lst files didn’t appear to correctly place code at the reset vector there either, though it somehow worked anyway (the project setup is gone, so I can’t actually test it).

I needed to get this project finished up, so I ended up using an A-Star Mini instead. The project was prototyped with an Arduino Nano, but I was hoping to use the lower cost and size P-Star Micro. (I don’t have any A-Star micros on hand.)

It would be nice to have a properly working, fully open source chain for programming the P-Stars with. Unfortunately, I’m not particularly versed in writing compilers, linkers, and such to fix it myself, nor do I have the time at the moment. I brought the topic up in the minimally populated #sdcc chat on freenode, but not much response. I haven’t really managed to connect to anyone else attempting to use SDCC for PIC either.

In a pinch, there is the free XC8 from Microchip, but with the reverse-optimizations… it’s really quite deplorable.

1 Like