-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hello-pfs154 const string "Hello World!" is placed in code memory byte by byte #2
Comments
Yes, it shall be implemented as one ret k per byte with k for the byte value. Best place is probably an SDCC tracker or mailing list. Philipp |
The transition to ret k should be complete in current SDCC (revision 10908). Philipp |
Hi, great work. Saw the ret k produced now. So much better than mini-C already :-) unfortunately a clean build does not produce a pdk14.lib (SVN branch revision 10908):
Also a disassembly of the final hex/bin file revealed that some CALL and GOTO targets are calculated incorrect (e.g. totally wrong destinations for last jump in main endless loop and call to external lib function "_puts") JS EDIT: pdk tools can now disassemble BIN files by supplying the OTP_ID: |
Ok, looks I'm wrong. Only last jump in main seems to end up nowhere. No specific correlation to a label. I investigated the wrong jump targets and it looks like it is caused by having the same ?local? label multiple times: e.g. in .asm intermediate output you get something like ; function send_bit ; function main ==> The goto in main jumps to the label in first function defining it (_send_bit). Also all "return" statements from inside interrupt should generate a "ret i". |
The return interrupts is fixed now. Regarding the labels, I wonder why it works for other architectures, but not pdk14. Philipp |
Hi, the assembly looks fine. Maybe assembler or linker is causing the problem. Meanwhile I debugged the HelloPFS154 (I ported it back to mini-c) and found some issues
__sfr __at(0x1d) tm2ct; after sending = true; insert this 3.) clkmd = 0x30; crashes since it disables IHRC 4.) timer prescalers and calculation are wrong (Not sure why is so big difference 52 <==> 60 , maybe because I was not tuning the IC) 5.) just a note: I pushed the ported and corrected version to the "simple-pdk-code-examples" |
@freepdk can you check again please? Compiling your updated hello.c gives me for the last goto in main:
0x73 * 2 == 0xE6 so it seems to be working for me. |
I made some fixes in the example code a few days ago. 1) and 2) are fixed as suggested. For 3) I had used the example from the datasheet, but looking at the details again, I now changed it (though I did it in two steps again, since the datasheet says, that the ILRC may not be disabled at the moment of the switch to the IHRC). I'll redo the calculations for 4) later and fix it then. |
Hi, I investigated a bit more (version 10921) and found out how to reproduce: When using the HElloPFS example the jump is translated fine (as @Rakete1111 reported). However when you insert more than 1 function call in the endless loop I get the problem. In order to produce something usable I was replacing the printf("...") with a sequence of putchars(...): main:
When using only one putchar('X') call in the loop the jump is fine. As soon as I insert 2 or more putchar calls the JUMP of the loop is pointing to nowhere. UPDATE: It also happens if I insert more stuff to _sdcc_external_startup() function (for quick test I used "__asm" ... "__endasm;" and added 10 NOPs inside. So maybe an overflow in assembler when calculating jump targets? => I added the code as attachment (shown on top) |
Well that's embarrassing, my bit arithmetic was wrong when the address uses more than 8 bits :(. Thanks, here's a patch to fix this @spth
|
GREAT 🥇 This fixed the goto problem. I can't express how happy I am :-) So maybe today is the day when I can stop using the PADAUK IDE :-) |
Hi, almost there. I found 2 more issues using revision 10926 (manually disassembled and commented the final output binary ):
main:
=> EDIT... found the source of __gptrget and it looks fine. Your idea was even better to manipulate the return pointer on stack for the long jump :-) |
Update, Form .lst file:
As you can see the .area CODE . area CONST is starting a new segment and therefore the address resets to 0. After removing the new segment starts the string was placed directly after code and the MOV A,#(___str1+0) produced some value. Unfortunately the value is still wrong and same value is inserted for lo and hi byte. When looking at other processor (e.g. STM8) .lst file of assert.asm (also contains a string) you can see that some ?relocation symbols are visible (r / s before the inserted address): assert.lst from stm8:
However the .lst file from pdk14 does not contain any of those markers:
|
Timer 2 setup should be fixed now. Philipp |
Nice :-) So still 2 things to go:
->
So the value of 0x38 would translate to:
-> instead of selecting IHRC/2 you select IHRC/8 The 0x3c translates to:
PADAUK IDE inserts CLKMD=0x34 when selecting IHRC/2 from wizard (it even shows "Clkmd = 34h") in wizzard) |
I see. I'll change it to
Philipp |
Relocation seems to be still broken also for DATA (interestingly, the values in the .map file look correct, but the ones in the .ihx look wrong). |
r10969 should fix @freepdk's issue along with some other relocation issues found. Feel free to check again :) |
@Rakete1111
In my case the string is at word position 0x103 (@0x206 in bytes if you look at the binary output) word offset, instruction, asm: 0x06 0x82 => 0x206 but should be 0x103 2). The MOV MEM,A was somehow translated wrong to a XOR MEM,A with latest version (see above).
|
@spth 0x008b: 0x2f03 MOV A, 0x03 |
Yes. Same for the offset from the start of the object, so in an array / struct in ROM, all members other than the first have a wrong address. Philipp |
@freepdk Should be fixed now in r10971. :) |
@spth @Rakete1111
Not sure if it was caused from relocate, linker or if pdk14.lib causes the trouble. Unfortunately the .rst / .lst file does not show the library code which is linked to it. So I used "dispdk 2AA1 output.bin" Here is the source I used. Compiled with revision 10971 (clean sdcc build) |
The .lst for __gptrget is in sdcc/device/lib/pdk14/__gptrget.lst. That instruction is an add a, #-1, which looks still ok in that .lst. Don't know what happened to it later. Philipp |
I have no idea what is causing this. I presume this is because a value of 0xFF seems to violate some the linker's assumption about relocatable addresses. Anyways, this is trivially fixable by just not emitting relocatable data for constant instructions, which makes sense anyways. :) Here's a patch @spth:
|
Thanks for the patch. Would the 0xff issue also affect variables that happen to be in memory at address 0xff? Philipp |
Output looks great now :-) Will try to write and execute it soon. @spth: PFS154 has 2 factory tuning values located as RET x at: 0x7ED: IHRCR_FACTORY BGTR is bandgap tuning register (the internal 1.2V reference) needed for ADC or COMParator I found that if you do not set the IHRCR (value stays =0) then the IC frequency is around 9.5MHz instead of 16MHz. A value of 0xFF will overclock it to around 24MHz :-) Details here: So either you insert a FIXED call to 0x7ED, get the IHRCR factory value in A and then move this IHRCR or you just use the "middle value" of 0x80 (which is the factory value of 5 PFS154 i checked) and move this to IHRCR directly. |
Is the value 0x7ed really a factory calibration value? From my understanding of the thread over at eevblog, it seemed to be a value written by the Padauk programmer, so the value at 0x7ed would not be available when programming the µC a different way. Philipp |
@0x7ED and 0x7EE are the 2 words of PFS154 which even a erase can not clear. Writer writes after calibration to 0x7FE So yes, the 2 values are coming from factory not erasable. My guess is that they introduced this so a PFS154 can be programed in circuit when writer has no access to the extra IO for tuning. |
No, it would affect addresses greater than 0x3FFF, i.e. using more than 14 bits. That's because those last bits are treated specially by the linker and if they are set, like by using |
I see. Where is this ihrcr register located? Philipp |
On PFS154 IHRCR is at IO 0x0B:
so init could simply do this (this might work for all PADAUK ICs since 0x80 seems to be the middle position of tuning, everything below tunes down the frequency and above tunes up, most likely the IC is designed to function with 16MHz when IHRCR is 0x80. Manufacturing differences might require slighty smaller / bigger values. Much different values can be used to tune to completely different frequencies):
On PFS154 you also could call the factory fixed address:
PFS173 has bigger memory so the position will be different for sure. I did not have the time to play with this type yet. Right now I focus on PFS154 to get a stable tool chain for compile, flash, execute, tune, debug, ... |
The current versions now use the factory calibration value for IHRC. Philipp |
Can you explain this cast and number magic?
ptr = 0x8000 + 0x7ED
|
The (unsigned char*) makes a pointer to unsigned char from the integer. The topmost bit indeed is used by SDCC to mark pointers to code memory. SDCC currently supports pdk14 and pdk15; I hope we will get pdk13 support soon; pdk16 support is much harder, and will take longer. Philipp |
GREAT! Everything is working. I did some small changes so the sample can be used with easy pdk programmer directly (move output to PA.7). It also can use a higher baud rate (115200). See PR #3 This issue can be closed :-) |
I tried to compile the hello pfs154 and saw that the const string "Hello World!" is placed in code memory const section byte by byte (2 byte per instruction word).
The PFS154 only can store 14 bit per instruction word which means that 2 bits of every second byte will be missing.
I think a byte array like "const char*" should use 1 instruction word per byte (wasting the upper bits).
BTW: Since this is a sdcc related thingy what would be best place to report this kind of problems?
The text was updated successfully, but these errors were encountered: