Thanks JS, I have done it, But I have a problem, the MCU some times would not boot after applying voltage to it, I thought maybe adding LVR would solve it, But the problem still remains, Do you have any other suggestion?
The PFS173 is powered from a DC/DC convertor, (the convertor has a slow startup voltage).
Dear JS
Thanks for your help, Unfortunately I have an analog oscilloscope, So I can not capture the wave form,
But I can share my code
Also This is the schematic, Note that Vin is coming from a secondary isolated winding from a flyback convertor.
Probably calibration is timing out. Put calibrate function call before delay loop
Maybe take a look at application note below. It clearly says that it's for PMC150/PMC153/ PMC156/PMC166 but who knows, maybe its 'bug' 'fixed' in orginal IDE .
http://www.padauk.com.tw//upload/ApplicationNote/PMC-APN006-PMC150_153_156_166_against_rapid_change_in_power_v003_EN_.pdf
Maybe create some minimal code that changes pin state (something like from AN oscilloscope plot) and make some tests.
Not exactly matching the problem, but the suggestion to set INTRQ to 0 is a good one.
Looks like in case IC (auto) resets some bits of INTRQ might be / get set and in case the interrupt handler does not process (clear all INTRQ bits) interrupt will run for ever (after exit of interrupt, IC sees at least one INTRQ bit is (still) set and interrupt is executed again, ..
EASY_PDK_INIT_SYSCLOCK_8MHZ(); //use 8MHz sysclock
EASY_PDK_CALIBRATE_IHRC(8000000,4000); //tune SYSCLK to 8MHz @ 4.000V
//EASY_PDK_FUSE(FUSE_SECURITY_OFF|FUSE_BOOTUP_SLOW);
//for(int cnt=0;cnt<10000;cnt++);
EASY_PDK_INIT_SYSCLOCK_8MHZ(); //use 8MHz sysclock
EASY_PDK_CALIBRATE_IHRC(8000000,4000); //tune SYSCLK to 8MHz @ 4.000V
JS, The new changes would not do any calibration!
Can you confirm that the UART TX can be put on PA6 pin, I'm using PFS173 8pin version
Regards
Where the INTRQ should be 0?
EASY_PDK_FUSE(FUSE_SECURITY_OFF|FUSE_BOOTUP_SLOW);
Now I just have commented out
JS, The old code would not do calibration either! it was doing it before
I have done one time this codeCode: [Select]EASY_PDK_FUSE(FUSE_SECURITY_OFF|FUSE_BOOTUP_SLOW);
Now I just have commented out
Thanks JS,
The Code does not make any calibration, No matter what I put in startup code, I have done all the possible combinations!
[build] ?ASlink-Warning-Invalid address for instruction
[build] file module area offset
[build] Refby CMakeFiles\spl loop CODE 000050
[build] Defin CMakeFiles\spl loop DATA 010000
[build]
I suspect that clocksSpent may be not word-aligned as LDT16 instruction requires and I just accidentally was being lucky when code successfully compiled for pdk13?Hello! I am having problems with reading 16-bit timer value using an open-source toolchain:
- When trying to read the T16C value directly in the code, I am receiving the "Unimplemented __sfr16 load" from SDCC.
- I tried to use line of ASM code "__asm__("ldt16 _clocksSpent");" (where clocksSpent is my global uint16_t variable name). This compiles for pdk13 (PMS150C), but when compiling for pdk15 (PFS173) I am getting the following linker error:Code: [Select][build] ?ASlink-Warning-Invalid address for instruction
I suspect that clocksSpent may be not word-aligned as LDT16 instruction requires and I just accidentally was being lucky when code successfully compiled for pdk13?
[build] file module area offset
[build] Refby CMakeFiles\spl loop CODE 000050
[build] Defin CMakeFiles\spl loop DATA 010000
[build]
Does anyone have similar error? Is there are any workaround for this?
; save context
push af
mov a, p
push af
mov a, p + 1
push af
; load TM16C
ldt16 p
mov a, p
mov _clocksSpent, a
mov a, p+1
mov _clocksSpent+1
; restore context
pop af
mov p + 1, a
pop af
mov p, a
pop af
However, if additional context saving is required, 13 cycles to load the word feels pretty slow in comparison to single ldt16 instruction. Maybe in the end, it is better to just move variable declarations around
Thanks, JS!
Yes, moving around variable declarations helps, works great as a temporary solution!
The second way (with virtual p register) seems more reliable, though. The only concern I have here is that I may accidentally clobber the previous (potentially important) p,a,f register values when running inline assembly? I suppose, additional push af / pop af and push/pop of with p register value may be required? Or p/a/f registers can be overwritten by the inline assembly without any consequences?Code: [Select]; save context
However, if additional context saving is required, 13 cycles to load the word feels pretty slow in comparison to single ldt16 instruction. Maybe in the end, it is better to just move variable declarations around
push af
mov a, p
push af
mov a, p + 1
push af
; load TM16C
ldt16 p
mov a, p
mov _clocksSpent, a
mov a, p+1
mov _clocksSpent+1
; restore context
pop af
mov p + 1, a
pop af
mov p, a
pop af
First check: Please check that you use latest "pfs173.h"
You can verify when you look in pfs173.h and find the following lines:
//set calibration macros
#define EASY_PDK_CALIBRATE_IHRC(frequency,millivolt) EASY_PDK_CALIBRATE_RC_M( EASY_PDK_CALTYPE_IHRC, 0x0B, frequency, millivolt )
Next check: Do you use the latest version of easypdk prog?
You can check by adding the -v option to easypdkprog command line:
easypdkprog -v --icname=PFS173 write build/lvrstartup.ihx
Searching programmer... found: /dev/tty.usbmodem1234567855AA1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.3
Erasing IC... done.
Blank check IC... done.
Writing IC (1592 words)... done.
Verifiying IC... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 5.00V ... calibration result: 8021146Hz (0x80) done.