jwestmoreland wrote on Saturday, July 28, 2007:
Hello,
I’m working on a port in which the portSTACK type needs to be 20-bits - has anyone done a port with this being 20-bits wide?
If so - can you elaborate on how you made it work?
Thanks,
John W.
rtel wrote on Saturday, July 28, 2007:
How does this work then at the processor level? Is the RAM 16bits wide, or 20bits wide?
Regards.
jwestmoreland wrote on Saturday, July 28, 2007:
Richard,
Registers can be used in either 16 or 20-bit mode.
Memory is addressable to 1MB; so addresses can go to 20-bits. RAM is 16-bits wide. Wordsize is 16 bits.
Issue I’m having is using memory above 64K. RAM resides in lower 64. Flash is only located above 64K.
Thanks,
John
jwestmoreland wrote on Saturday, July 28, 2007:
Richard,
I guess I should’ve said real issue is pushing 20-bit registers on the stack and how to handle in port.c …
Thanks,
John W.
rtel wrote on Saturday, July 28, 2007:
The PIC24 does simlar things. Pointers are 16bits, but the address space is 24bits - which makes it seem tricky to point to the start address of a task. Luckily in this case the compiler takes care of it for you through the use of a poitner jump table.
So what does the processor do when it stacks 20bit registers into 16bit wide RAM? (I could always read the datasheet but I’m a bit pushed for time). Does it just loose 4bits of the third register byte? The MSP430 has quite a few registers, so this would seem wastefull, but maybe this is not a problem as you get a lot more memory space to play with.
Is your problem then that you cannot declare the stack type as 16bits, as they are in fact 20bits, and you cannot declare the stack type as 32bits, as this gives you a whole byte (plus the 4 bits) too much (sorry for basic questions). Seems a bit tricky.
Regards.
jwestmoreland wrote on Saturday, July 28, 2007:
Richard,
Yes - I can’t declare portSTACK as 20-bits wide.
From the datasheet on a push:
The stack pointer (SP) is decremented by two (byte and word
operands) or by four (address-word operand) before the write operation.
From the datasheet for a pop:
The stack pointer SP is incremented by two (byte and
word operands) and by four (address-word operand).
Thanks,
John
rtel wrote on Saturday, July 28, 2007:
It sounds like it is using 32bits per 20bit value, in which case this would make the stack type unsigned long. You would have to setup the initial stack in port.c using 4bytes per 20bit register.
Regards.
jwestmoreland wrote on Saturday, July 28, 2007:
Richard,
Yes - that’s what I’m trying to do now.
I’ll let you know how it goes.
Thanks,
John
jwestmoreland wrote on Saturday, July 28, 2007:
Richard,
Looks like everything is OK up until the portRESTORE_CONTEXT when xPortStartScheduler is called - as soon as the reti is called - the app goes into the weeds.
Everything looks ok - the starting addr of the 1st task is where it’s supposed to be - but it’s 32 bits now vs. 16 (or 20) - maybe that’s where things are going wrong…
Regards,
John
rtel wrote on Saturday, July 28, 2007:
In your debugger, are you able to break in an interrupt routine, then inspect the stack just before a compiler generated reti instruction, so you can inspect the stack to see how the address is stored? You can then copy this. Maybe there is some magic somewhere, as per the PIC24 jump table mentioned previously.
Regards.
jwestmoreland wrote on Saturday, July 28, 2007:
Richard,
One of the issues is in port.c - if everything is made 32-bits - including pxCode and portFLAGS_INT_ENABLED - from the databook
on RETI:
RETI Return from interrupt
Syntax RETI
Operation @SP → SR.15:0 Restore saved status register SR with PC.19:16
SP + 2 → SP
@SP → PC.15:0 Restore saved program counter PC.15:0
SP + 2 → SP House keeping
Description The status register is restored to the value at the beginning of the interrupt
service routine. This includes the four MSBs of the program counter PC.19:16.
The stack pointer is incremented by two afterwards.
The 20-bit PC is restored from PC.19:16 (from same stack location as the
status bits) and PC.15:0. The 20-bit program counter is restored to the value
at the beginning of the interrupt service routine. The program continues at the
address following the last executed instruction when the interrupt was granted.
The stack pointer is incremented by two afterwards.
Looks like 16-bit values are expected - not 32-bit. I did a fix up on this and got a little further down the road - but the app still goes in the weeds.
Since I had the portFLAGS_INT_ENABLED set to be 0x08 - this was stored as 0x00000008 - and after the RETI was done - the 0x0008 was being grabbed by the SR but the
PC was being set to 0x0000; The task’s address was after that - stored as 0x0000383E; - but the PC didn’t get that far since jumping to weed-land at 0x0000;
I’m going to have to stop for today but I’ll be back at it this weekend.
Thanks,
John
rtel wrote on Saturday, July 28, 2007:
So 4 bits of the program counter are stored in the unused bits of the stack pointer. Looks like you are going to have to do some shifting of values in pxPortInitialiseStack() to get everything in the right place. There is a port that does this already I think (?) but I cannot remember which processor it is.
Can you provide me with a part number or a link to a document that describes the architecture? I’ve looked at a couple on the TI site but they seem to have 16bit program counters.
Regards.
jwestmoreland wrote on Saturday, July 28, 2007:
Richard,
Yes, I did some shifting at the beginning of xPortInitializeStack() but more needs to be done.
The MPS430 Family is the MSP430FG4XXX - the one’s I’m using specifically are the
MSP430FG4618 and
MSP430FG4619
The datasheet can be downloaded from:
http://focus.ti.com/lit/ds/symlink/msp430fg4618.pdf
The UG can be downloaded from:
http://focus.ti.com/lit/ug/slau056f/slau056f.pdf
Chip errata can be downloaded from:
http://focus.ti.com/lit/er/slaz028f/slaz028f.pdf
Main Page for the 'FG4618:
http://focus.ti.com/docs/prod/folders/print/msp430fg4618.html
Thanks!
John
jwestmoreland wrote on Sunday, July 29, 2007:
Richard,
I’m getting to the first vTaskDelayUntil - and when the RETA is executed - it bombs.
It looks like the SP may be off by one word - I just took a closer look in the debugger - and for some reason - this is what it looks like -
there’s a popw.m #6,R11 in vPortYield(); - and it looks like where the SP is pointing is SR info - (one word) - then the address of what should be executed - like
what you’d expect in a reti - but in this case it’s a RETA - from the datasheet:
* RETA Return from subroutine
Syntax RETA
Operation @SP → PC.15:0 LSBs (15:0) of saved PC to PC.15:0
SP + 2 → SP
@SP → PC.19:16 MSBs (19:16) of saved PC to PC.19:16
SP + 2 → SP
Emulation MOVA @SP+,PC
Description The 20-bit return address information, pushed onto the stack by a CALLA
instruction, is restored to the program counter PC. The program continues at
the address following the subroutine call. The status register bits SR.11:0 are
not affected. This allows the transfer of information with these bits.
So - this is different than RETI - the SR isn’t affected - so the PC is picking up what looks like the SR info and then entering weed-land.
But - it looks like the SP is pointing to what would be expected by a RETI vs. a RETA.
At least this is progress…
Thanks,
John W.
jwestmoreland wrote on Sunday, July 29, 2007:
Actually the above is in taskYield() - immediately following the call to vPortYield()…
John
adarkar9 wrote on Monday, July 30, 2007:
It is interesting to note that the stacking of the address is different between CALLA/RETA and Interrupt/RETI. In the interrupt case PC.15:0 is pushed first, while in the CALLA case PC.15:0 is pushed last.
jwestmoreland wrote on Monday, July 30, 2007:
Looks like the issue is boiling down to differences in RETI, RETA, and RET.
Regards,
John
jwestmoreland wrote on Friday, August 03, 2007:
Richard,
After doing the ‘shift fix-up’ - could that affect the tskTCB down the road? I’ve looked that this and don’t think so - but wanted to see what
you thought.
Thanks,
John
jwestmoreland wrote on Friday, August 03, 2007:
1st context switch from IDLE to LEDx task is where this is currently dieing…