Hi
I wanna convert a frequency in Hz to its cycle duration in µs. Example, frequency is 440, result shall be 2273
I tried this:
int round(double number){
return (number >= 0) ? (int)(number + 0.5) : (int)(number - 0.5);
}
int FrqGetUs(int frq){
double period;
period=(1/frq)*1000000;
return (round(period));
}
period=FrqGetUs(440);
but it doesn't work. In circuit, the µC appears to be caught in a reset-loop, and while in debugger, the µC freezes somewhere in ASM on the calculation of period=(1/frq)*100000; debugger reports "Communication with target lost".
Whats wrong with it?
Original Attachment has been moved to: pdeclaration.h.zip
Original Attachment has been moved to: MCUinit.c.zip
Original Attachment has been moved to: MCUinit.h.zip
Original Attachment has been moved to: drehteller_v2.zip
Original Attachment has been moved to: lib_hc08c_device_include.zip
I would also check the possibility of stack corruption (either due to program error, or insufficient stack allocation) which might also cause resets (e.g., due to illegal opcode or address). Although this does not seem to explain the difference in real vs debugger, but it's worth investigating (e.g., is the debugger version the exact same binary?)
Hey you guys, thanks for helping. Im just within this debugger issue and found out: If I remove some code, it works. If I remove some other code instead, it works as well. Could it be possible that I'm simply running out of flash? However, I'd expect a warning if I try to write more code than the targets size is. And well, if the debugger access via MON08 may allocate some extra address space, that could be the explaination why it works in circuit but not in debug.
(I came across this cause I added two more example for() loops to the code, making it finally failing in circuit as well).
Best regards
Holger
Anybody else who can help? I hardly cannot believe that the 4k FLASH is already full. I have roughly 4K C sourcecode (including comments, formatings and stuff) and I thought that ASM is more compact than C
Yes, everything else being equal, ASM is always shorter than C but, in case you hadn't noticed, your code is in C, not ASM. :smileyhappy:
It's hard to tell what your actual problem might be.
Looking at the produced map file, you should be able to tell how much room your code takes, and where (in case some falls outside valid memory ranges).
Your programmer should also warn you if you try to put code outside the specific variant's memory ranges. (Hint: Are you using the correct variant setting in your compiler and/or programmer?)
If indeed you have an insufficient memory problem I suspect you can easily solve it by just removing the floating point library from your code. Floating-point is notoriously expensive in terms of code size (and even execution speed).
You can always do any basic calculations (like the ones you showed) using plain integer arithmetic. This should lower the code space needed for your app possibly enough to solve your problem.
Without having access to your full project details, it's hard for someone to offer you more advice.
Yes, the code is written in C. I thought it will be compiled to ASM by the IDE before its became loaded to the FLASH. However, this may not be that effective than directly coding in ASM (but the one and only time i wrote ASM was on 6502 - 20 years ago).
I've got a warning "Address out of range" sometimes during debugging, but not while programming. Probably this is an issue with the P&E interface - or better to say - it's software. The variant should be selected correctly.
I think there may be still the float library loaded, I'll doublecheck this later.
Apart from this, there is no problem to give access to the full code, it's not confidential. I can upload it later this evening.
Thanks so far.
Holger
>If I recall correctly, this was a branch or jump instruction where that warning appeared. The device is MC68HC908JL3ECDWE.
OK, if it's jumping to an illegal address for this MCU variant, it would cause a reset. Or, if it jumps to an area where there is NO valid opcode (e.g., data or garbage), again it would cause a reset.
To get rid of one possible problem at a time (not necessarily in this order):
* Verify object code address range is valid (by examining the produced map file.)
* Verify the JMP instruction is jumping where it should. If not, ask why. E.g., if it jumps to the correct label, but it turns out to be in nowhere land, then maybe your code has wrapped around the 64K limit, or some similar problem.
* Try to remove floating point, and make needed changes to your code.
And finally, the C source code, which is surely far from good:
#include <hidef.h> /* for EnableInterrupts macro */
#include "derivative.h" /* include peripheral declarations */
#include "pdeclaration.h" /* ports declarations */
void MCU_init(void); /* Device initialization function declaration */
int FrqGetUs(int frq){
int period;
period=1000000/frq;
return (period);
}
void delayus(int delay){
TSC_TRST=1;
TMOD=(delay*3);
TSC_TSTOP=0;
while (TSC_TOF == 0);
TSC_TSTOP=1;
TSC_TOF = 0;
}
/*
Calculation of correction steps:
360 degrees equals 3350 steps
Correction steps = 3350 minus (rounded (3350 divided by pictures per turn) * pictures per turn)
Correction position = rounded(3350 divided by correction steps)
*/
void move(int picinit, int motspeed){
int pause;
int pics;
int steps;
int xtrastep = 0;
int totalsteps = 0;
int stepinit = 0;
int stepmiss = 0;
int accdcc = 0;
stepinit = (3350 / picinit);
if (3350 / (3350 - (stepinit*picinit)) > 0) {
stepmiss = 3350 / (3350 - (stepinit*picinit));
}
for ( pics = 0; pics < picinit;) {
for ( steps = 0; steps < stepinit;) {
MOTclk = !MOTclk;
for( pause = 0; pause < motspeed; pause++);
steps++;
xtrastep++;
totalsteps++;
if (stepmiss !=0) { /* Exact 360 deg step correction routine */
if (xtrastep == stepmiss) {
MOTclk = !MOTclk;
for( pause = 0; pause < motspeed; pause++);
totalsteps++;
xtrastep = 0;
}
}
if (BTNstop == DOWN) { /* Stop button pressed? */
LEDstart = 0;
LEDstop = 1;
while (totalsteps < 3350) {
MOTclk = !MOTclk;
for( pause = 0; pause < motspeed; pause++);
totalsteps++;
}
LEDstop = 0;
pics = picinit;
steps = stepinit;
}
}
for( pause = 0; pause < 30000; pause++); /* Placeholder for Infrared xmtr routine for DSLR control */
pics ++;
}
}
void main(void){
int test;
int period;
MCU_init();
MOTrst = 1;
EnableInterrupts;
for (;;) { /* main loop*/
if (BTNstart == DOWN) {
if (MODEword == 14){ /* SWITCH POSTITON 1 - 10 pics */
MOTmode = HALF;
LEDstart = 1;
move(10,200);
LEDstart = 0;
}
if (MODEword == 13){ /* SWITCH POSTITON 2 - 20 pics */
MOTmode = HALF;
LEDstart = 1;
move(20,200);
LEDstart = 0;
}
if (MODEword == 12){ /* SWITCH POSTITON 3 - 25 pics */
MOTmode = HALF;
LEDstart = 1;
move(25,200);
LEDstart = 0;
}
if (MODEword == 11){ /* SWITCH POSTITON 4 - 30 pics */
MOTmode = HALF;
LEDstart = 1;
move(30,200);
LEDstart = 0;
}
if (MODEword == 10){ /* SWITCH POSTITON 5 - 35 pics */
MOTmode = HALF;
LEDstart = 1;
move(35,200);
LEDstart = 0;
}
if (MODEword == 9){ /* SWITCH POSTITON 6 - 40 pics */
MOTmode = HALF;
LEDstart = 1;
move(40,200);
LEDstart = 0;
}
if (MODEword == 8){ /* SWITCH POSTITON 7 - 45 pics */
MOTmode = HALF;
LEDstart = 1;
move(45,200);
LEDstart = 0;
}
if (MODEword == 7){ /* SWITCH POSTITON 8 - 50 pics */
MOTmode = HALF;
LEDstart = 1;
move(50,200);
LEDstart = 0;
}
if (MODEword == 6){ /* SWITCH POSTITON 9 - 60 pics */
MOTmode = HALF;
LEDstart = 1;
move(60,200);
LEDstart = 0;
}
if (MODEword == 15){ /* SWITCH POSTITON 10 - Testmode */
MOTmode = HALF;
LEDstart = 1;
period=FrqGetUs(440);
for (test=0; test<1000; test++){
delayus(period);
MOTclk = !MOTclk;
}
period=FrqGetUs(880);
for (test=0; test<1000; test++){
delayus(period);
MOTclk = !MOTclk;
}
LEDstart = 0;
}
}
}
}
First of all, I cannot reproduce the warning. I'd tried so many things the past days, that I can't recall exactly under what circumstances it happens. What I know is, it was shown only in full chip simulation, while in-circuit the connection to the target gots lost instead.
Then I took a look on the project.map file (it is still the version with floating point), but thats double dutch for me. I'm going to post it here, maybe you can point on the important things for me:
Processor : Freescale HC08
Memory Model: SMALL
File Format : ELF\DWARF 2.0
Linker : SmartLinker V-5.0.34 Build 8120, Apr 30 2008
*********************************************************************************************
FILE SECTION
---------------------------------------------------------------------------------------------
MC68HC908JL3.C.o Model: SMALL, Lang: ANSI-C
Start08.c.o Model: SMALL, Lang: ANSI-C
MCUinit.c.o Model: SMALL, Lang: ANSI-C
main_v1_2.c.o Model: SMALL, Lang: ANSI-C
RTSHC08.C.o (ansi.lib) Model: SMALL, Lang: ANSI-C
*********************************************************************************************
STARTUP SECTION
---------------------------------------------------------------------------------------------
Entry point: 0xEC8C (_Startup)
_startupData is allocated at 0xEC95 and uses 6 Bytes
extern struct _tagStartup {
unsigned nofZeroOut 0
_Copy *toCopyDownBeg 0xF369
} _startupData;
*********************************************************************************************
SECTION-ALLOCATION SECTION
Section Name Size Type From To Segment
---------------------------------------------------------------------------------------------
.init 149 R 0xEC00 0xEC94 ROM
.startData 10 R 0xEC95 0xEC9E ROM
.text 1738 R 0xEC9F 0xF368 ROM
.copy 2 R 0xF369 0xF36A ROM
.abs_section_0 1 N/I 0x0 0x0 .absSeg0
.abs_section_1 1 N/I 0x1 0x1 .absSeg1
.abs_section_3 1 N/I 0x3 0x3 .absSeg2
.abs_section_4 1 N/I 0x4 0x4 .absSeg3
.abs_section_5 1 N/I 0x5 0x5 .absSeg4
.abs_section_7 1 N/I 0x7 0x7 .absSeg5
.abs_section_a 1 N/I 0xA 0xA .absSeg6
.abs_section_d 1 N/I 0xD 0xD .absSeg7
.abs_section_1a 1 N/I 0x1A 0x1A .absSeg8
.abs_section_1b 1 N/I 0x1B 0x1B .absSeg9
.abs_section_1d 1 N/I 0x1D 0x1D .absSeg10
.abs_section_1e 1 N/I 0x1E 0x1E .absSeg11
.abs_section_1f 1 N/I 0x1F 0x1F .absSeg12
.abs_section_20 1 N/I 0x20 0x20 .absSeg13
.abs_section_25 1 N/I 0x25 0x25 .absSeg14
.abs_section_28 1 N/I 0x28 0x28 .absSeg15
.abs_section_3c 1 N/I 0x3C 0x3C .absSeg16
.abs_section_3d 1 N/I 0x3D 0x3D .absSeg17
.abs_section_3e 1 N/I 0x3E 0x3E .absSeg18
.abs_section_fe00 1 N/I 0xFE00 0xFE00 .absSeg19
.abs_section_fe01 1 N/I 0xFE01 0xFE01 .absSeg20
.abs_section_fe03 1 N/I 0xFE03 0xFE03 .absSeg21
.abs_section_fe04 1 N/I 0xFE04 0xFE04 .absSeg22
.abs_section_fe05 1 N/I 0xFE05 0xFE05 .absSeg23
.abs_section_fe06 1 N/I 0xFE06 0xFE06 .absSeg24
.abs_section_fe08 1 N/I 0xFE08 0xFE08 .absSeg25
.abs_section_fe09 1 N/I 0xFE09 0xFE09 .absSeg26
.abs_section_fe0e 1 N/I 0xFE0E 0xFE0E .absSeg27
.abs_section_ffff 1 N/I 0xFFFF 0xFFFF .absSeg28
.abs_section_21 2 N/I 0x21 0x22 .absSeg29
.abs_section_23 2 N/I 0x23 0x24 .absSeg30
.abs_section_26 2 N/I 0x26 0x27 .absSeg31
.abs_section_29 2 N/I 0x29 0x2A .absSeg32
.abs_section_fe0c 2 N/I 0xFE0C 0xFE0D .absSeg33
.abs_section_ffde 34 R 0xFFDE 0xFFFF .absSeg34
.stack 48 R/W 0x80 0xAF Z_RAM
Summary of section sizes per section type:
READ_ONLY (R): 78D (dec: 1933)
READ_WRITE (R/W): 30 (dec: 48)
NO_INIT (N/I): 27 (dec: 39)
*********************************************************************************************
VECTOR-ALLOCATION SECTION
Address InitValue InitFunction
---------------------------------------------------------------------------------------------
*********************************************************************************************
OBJECT-ALLOCATION SECTION
Name Module Addr hSize dSize Ref Section RLIB
---------------------------------------------------------------------------------------------
MODULE: -- MC68HC908JL3.C.o --
- PROCEDURES:
- VARIABLES:
_PTA 0 1 1 42 .abs_section_0
_PTB 1 1 1 4 .abs_section_1
_PTD 3 1 1 12 .abs_section_3
_DDRA 4 1 1 2 .abs_section_4
_DDRB 5 1 1 2 .abs_section_5
_DDRD 7 1 1 2 .abs_section_7
_PDCR A 1 1 2 .abs_section_a
_PTAPUE D 1 1 3 .abs_section_d
_KBSCR 1A 1 1 0 .abs_section_1a
_KBIER 1B 1 1 0 .abs_section_1b
_INTSCR 1D 1 1 0 .abs_section_1d
_CONFIG2 1E 1 1 1 .abs_section_1e
_CONFIG1 1F 1 1 1 .abs_section_1f
_TSC 20 1 1 5 .abs_section_20
_TSC0 25 1 1 0 .abs_section_25
_TSC1 28 1 1 0 .abs_section_28
_ADSCR 3C 1 1 0 .abs_section_3c
_ADR 3D 1 1 0 .abs_section_3d
_ADICLK 3E 1 1 0 .abs_section_3e
_BSR FE00 1 1 0 .abs_section_fe00
_RSR FE01 1 1 0 .abs_section_fe01
_BFCR FE03 1 1 0 .abs_section_fe03
_INT1 FE04 1 1 0 .abs_section_fe04
_INT2 FE05 1 1 0 .abs_section_fe05
_INT3 FE06 1 1 0 .abs_section_fe06
_FLCR FE08 1 1 0 .abs_section_fe08
_FLBPR FE09 1 1 0 .abs_section_fe09
_BRKSCR FE0E 1 1 0 .abs_section_fe0e
_COPCTL FFFF 1 1 0 .abs_section_ffff
_TCNT 21 2 2 0 .abs_section_21
_TMOD 23 2 2 1 .abs_section_23
_TCH0 26 2 2 0 .abs_section_26
_TCH1 29 2 2 0 .abs_section_29
_BRK FE0C 2 2 0 .abs_section_fe0c
MODULE: -- Start08.c.o --
- PROCEDURES:
loadByte EC00 17 23 5 .init
Init EC17 75 117 1 .init
_Startup EC8C 9 9 1 .init
- VARIABLES:
_startupData EC95 6 6 6 .startData
- LABELS:
__SEG_END_SSTACK B0 0 0 1
MODULE: -- MCUinit.c.o --
- PROCEDURES:
MCU_init EC9F 33 51 1 .text
- VARIABLES:
_vect FFDE 22 34 0 .abs_section_ffde
MODULE: -- main_v1_2.c.o --
- PROCEDURES:
FrqGetUs ECD2 14 20 1 .text
delayus ECE6 22 34 1 .text
move ED08 16F 367 9 .text
main EE77 2A9 681 68 .text
- VARIABLES:
MODULE: -- RTSHC08.C.o (ansi.lib) --
- PROCEDURES:
_PUSH_ARGS_L F120 2D 45 1 .text
_ENTER_BINARY_L_LC F14D 23 35 1 .text
_IDIVMOD F170 69 105 1 .text
_SPLITSIGN F1D9 1C 28 1 .text
_LDIVMOD F1F5 CA 202 2 .text
_NEG_L_HX F2BF 13 19 2 .text
_ABS_L_HX F2D2 6 6 2 .text
_SPLITSIGN_L F2D8 A 10 1 .text
_LDIVS_k_is_k_div_j F2E2 2C 44 1 .text
_IMUL F30E 2A 42 2 .text
_IDIVS F338 1E 30 3 .text
_LDIVS_LC F356 6 6 1 .text
_SEXT16_32 F35C D 13 1 .text
- VARIABLES:
*********************************************************************************************
MODULE STATISTIC
Name Data Code Const
---------------------------------------------------------------------------------------------
MC68HC908JL3.C.o 39 0 0
Start08.c.o 0 149 0
MCUinit.c.o 0 51 34
main_v1_2.c.o 0 1102 0
RTSHC08.C.o (ansi.lib) 0 585 0
other 48 10 2
*********************************************************************************************
SECTION USE IN OBJECT-ALLOCATION SECTION
---------------------------------------------------------------------------------------------
SECTION: ".text"
MCU_init FrqGetUs delayus move main _PUSH_ARGS_L _ENTER_BINARY_L_LC _IDIVMOD
_SPLITSIGN _LDIVMOD _NEG_L_HX _ABS_L_HX _SPLITSIGN_L _LDIVS_k_is_k_div_j
_IMUL _IDIVS _LDIVS_LC _SEXT16_32
SECTION: ".init"
loadByte Init _Startup
SECTION: ".abs_section_0"
_PTA
SECTION: ".abs_section_1"
_PTB
SECTION: ".abs_section_3"
_PTD
SECTION: ".abs_section_4"
_DDRA
SECTION: ".abs_section_5"
_DDRB
SECTION: ".abs_section_7"
_DDRD
SECTION: ".abs_section_a"
_PDCR
SECTION: ".abs_section_d"
_PTAPUE
SECTION: ".abs_section_1a"
_KBSCR
SECTION: ".abs_section_1b"
_KBIER
SECTION: ".abs_section_1d"
_INTSCR
SECTION: ".abs_section_1e"
_CONFIG2
SECTION: ".abs_section_1f"
_CONFIG1
SECTION: ".abs_section_20"
_TSC
SECTION: ".abs_section_25"
_TSC0
SECTION: ".abs_section_28"
_TSC1
SECTION: ".abs_section_3c"
_ADSCR
SECTION: ".abs_section_3d"
_ADR
SECTION: ".abs_section_3e"
_ADICLK
SECTION: ".abs_section_fe00"
_BSR
SECTION: ".abs_section_fe01"
_RSR
SECTION: ".abs_section_fe03"
_BFCR
SECTION: ".abs_section_fe04"
_INT1
SECTION: ".abs_section_fe05"
_INT2
SECTION: ".abs_section_fe06"
_INT3
SECTION: ".abs_section_fe08"
_FLCR
SECTION: ".abs_section_fe09"
_FLBPR
SECTION: ".abs_section_fe0e"
_BRKSCR
SECTION: ".abs_section_ffff"
_COPCTL
SECTION: ".abs_section_21"
_TCNT
SECTION: ".abs_section_23"
_TMOD
SECTION: ".abs_section_26"
_TCH0
SECTION: ".abs_section_29"
_TCH1
SECTION: ".abs_section_fe0c"
_BRK
SECTION: ".abs_section_ffde"
_vect
*********************************************************************************************
OBJECT LIST SORTED BY ADDRESS
Name Addr hSize dSize Ref Section RLIB
---------------------------------------------------------------------------------------------
_PTA 0 1 1 42 .abs_section_0
_PTB 1 1 1 4 .abs_section_1
_PTD 3 1 1 12 .abs_section_3
_DDRA 4 1 1 2 .abs_section_4
_DDRB 5 1 1 2 .abs_section_5
_DDRD 7 1 1 2 .abs_section_7
_PDCR A 1 1 2 .abs_section_a
_PTAPUE D 1 1 3 .abs_section_d
_KBSCR 1A 1 1 0 .abs_section_1a
_KBIER 1B 1 1 0 .abs_section_1b
_INTSCR 1D 1 1 0 .abs_section_1d
_CONFIG2 1E 1 1 1 .abs_section_1e
_CONFIG1 1F 1 1 1 .abs_section_1f
_TSC 20 1 1 5 .abs_section_20
_TCNT 21 2 2 0 .abs_section_21
_TMOD 23 2 2 1 .abs_section_23
_TSC0 25 1 1 0 .abs_section_25
_TCH0 26 2 2 0 .abs_section_26
_TSC1 28 1 1 0 .abs_section_28
_TCH1 29 2 2 0 .abs_section_29
_ADSCR 3C 1 1 0 .abs_section_3c
_ADR 3D 1 1 0 .abs_section_3d
_ADICLK 3E 1 1 0 .abs_section_3e
loadByte EC00 17 23 5 .init
Init EC17 75 117 1 .init
_Startup EC8C 9 9 1 .init
MCU_init EC9F 33 51 1 .text
FrqGetUs ECD2 14 20 1 .text
delayus ECE6 22 34 1 .text
move ED08 16F 367 9 .text
main EE77 2A9 681 68 .text
_PUSH_ARGS_L F120 2D 45 1 .text
_ENTER_BINARY_L_LC F14D 23 35 1 .text
_IDIVMOD F170 69 105 1 .text
_SPLITSIGN F1D9 1C 28 1 .text
_LDIVMOD F1F5 CA 202 2 .text
_NEG_L_HX F2BF 13 19 2 .text
_ABS_L_HX F2D2 6 6 2 .text
_SPLITSIGN_L F2D8 A 10 1 .text
_LDIVS_k_is_k_div_j F2E2 2C 44 1 .text
_IMUL F30E 2A 42 2 .text
_IDIVS F338 1E 30 3 .text
_LDIVS_LC F356 6 6 1 .text
_SEXT16_32 F35C D 13 1 .text
_BSR FE00 1 1 0 .abs_section_fe00
_RSR FE01 1 1 0 .abs_section_fe01
_BFCR FE03 1 1 0 .abs_section_fe03
_INT1 FE04 1 1 0 .abs_section_fe04
_INT2 FE05 1 1 0 .abs_section_fe05
_INT3 FE06 1 1 0 .abs_section_fe06
_FLCR FE08 1 1 0 .abs_section_fe08
_FLBPR FE09 1 1 0 .abs_section_fe09
_BRK FE0C 2 2 0 .abs_section_fe0c
_BRKSCR FE0E 1 1 0 .abs_section_fe0e
_vect FFDE 22 34 0 .abs_section_ffde
_COPCTL FFFF 1 1 0 .abs_section_ffff
*********************************************************************************************
UNUSED-OBJECTS SECTION
---------------------------------------------------------------------------------------------
NOT USED PROCEDURES
RTSHC08.C.o (ansi.lib):
_PUSH_ARGS_D _ENTER_UNARY_L _ENTER_UNARY_L64 _ENTER_UNARY_L64_4
_ENTER_BINARY_L _ENTER_BINARY_L_RC _ENTER_BINARY_L64 _ENTER_BINARY_L64_LC
_ENTER_BINARY_L64_RC _LADD_k_is_k_plus_j _k_is_k_plus_j_l _k_is_k_plus_j_i
_LSUB_k_is_k_minus_j _LAND_k_is_k_and_j _LOR_k_is_k_or_j _LXOR_k_is_k_xor_j
_LMUL_k_is_k_mul_j _LMODU_k_is_k_mod_j _LDIVU_k_is_k_div_j
_LMODS_k_is_k_mod_j _LCMP_k_rel_j _BMULS _BDIVS _BMODS _IDIVU _IMODS _IMODU
_IDIVU_8 _IMODU_8 _IASR _ILSR _ILSL _ICMP _LINC _LDEC _LNEG _LNOT _LADD
_LADD_RC _LSUB _LSUB_LC _LSUB_RC _LAND _LAND_RC _LOR _LOR_RC _LXOR _LXOR_RC
_LMUL _LMUL_RC _LDIVS _LDIVS_RC _LDIVU _LDIVU_LC _LDIVU_RC _LMODS _LMODS_LC
_LMODS_RC _LMODU _LMODU_LC _LMODU_RC _LASR _LLSR _LLSL _LCMP _LCMP_RC _COPY
_COPY_L _POP32 _POP64 _STORE32 _STORE64 _SEXT8_32 _CALL _Jump_Table_Addr
_Jump_Table_Offset _Jump_Table_Header_Addr _Jump_Table_Header_Offset
_Search_Table_16_Addr _Search_Table_16_Offset _Search_Table_8_Addr
_Search_Table_8_Offset _PUSH_CC _POP_CC _CONV_FAR_TO_NEAR _CONV_FAR_TO_LINEAR
_CONV_LINEAR_TO_FAR F_CLRK F_CLRK_Unary F_NANK F_INFK F_INFK_Unary F_TLK
F_XGKL _UNPACK_k_to_K _UNPACK_k_to_K_Unary _UNPACK_j_to_L _PACK_K_to_k
_PACK_K_to_k_Unary F_NORMK _FADD_K_is_K_plus_L _FMUL_K_is_K_times_L
_FDIV_K_is_L_div_K _F_LONGK _F_FLOATK _FCMP_k_rel_j _FADD_Common _FSUB_Common
_FMUL_Common _FDIV_Common _FADD _FADD_RC _FSUB _FSUB_RC _FSUB_LC _FMUL
_FMUL_RC _FDIV _FDIV_RC _FDIV_LC _FSTRUNC _FUTRUNC _FNEG _FABS _FCMP _FCMP_RC
_FINC _FDEC _FSFLOAT _FUFLOAT D_TLK D_TLRes D_TKRes D_XGKL D_CLRK
D_CLRK_Unary D_NANK D_NANK_Unary D_INFK D_INFK_Unary _DUNPACK_k_to_K
_DUNPACK_k_to_K_Unary _DUNPACK_j_to_L _DPACK_K_to_k _DPACK_K_to_k_Unary
D_NORMK_Unary D_NORMK _DADD_K_is_K_plus_L _DMUL_K_is_K_times_L
_DDIV_K_is_L_div_K _DCMP_k_rel_j _D_FLOATK _D_LONGK _D_FTODK _D_DTOFK
_DADD_Common _DSUB_Common _DMUL_Common _DDIV_Common _DADD _DADD_RC _DSUB
_DSUB_RC _DSUB_LC _DMUL _DMUL_RC _DDIV _DDIV_LC _DDIV_RC _DCMP _DCMP_RC _DINC
_DDEC _DNEG _DABS _DSFLOAT _DUFLOAT _DSTRUNC _DUTRUNC _DSHORT _DLONG
NOT USED VARIABLES
RTSHC08.C.o (ansi.lib):
_PowOfTwo_8 _PowOfTwo_16 _PowOfTwo_32 plus1 minus1 plus1d minus1d errno
*********************************************************************************************
COPYDOWN SECTION
---------------------------------------------------------------------------------------------
------- ROM-ADDRESS: 0xF369 ---- SIZE 2 ---
Filling bytes inserted
0000
*********************************************************************************************
OBJECT-DEPENDENCIES SECTION
---------------------------------------------------------------------------------------------
Init USES _startupData loadByte
_Startup USES __SEG_END_SSTACK Init main
MCU_init USES _CONFIG1 _CONFIG2 _PTAPUE _DDRA _PTB _DDRB _PTD
_PDCR _DDRD
FrqGetUs USES _SEXT16_32 _LDIVS_LC
delayus USES _TSC _IMUL _TMOD
move USES _IDIVS _IMUL move _PTA _PTD
main USES MCU_init _PTB main _PTA _PTD move delayus
FrqGetUs
_ENTER_BINARY_L_LC USES _PUSH_ARGS_L
_SPLITSIGN USES _IDIVMOD
_LDIVMOD USES _LDIVMOD
_ABS_L_HX USES _NEG_L_HX
_SPLITSIGN_L USES _ABS_L_HX
_LDIVS_k_is_k_div_j USES _SPLITSIGN_L _LDIVMOD _NEG_L_HX
_IDIVS USES _SPLITSIGN
_LDIVS_LC USES _ENTER_BINARY_L_LC _LDIVS_k_is_k_div_j
_vect USES _Startup
*********************************************************************************************
DEPENDENCY TREE
*********************************************************************************************
main and _Startup Group
|
+- main
| |
| +- MCU_init
| |
| +- move
| | |
| | +- _IDIVS
| | | |
| | | +- _SPLITSIGN
| | | |
| | | +- _IDIVMOD
| | |
| | +- _IMUL
| |
| +- delayus
| | |
| | +- _IMUL (see above)
| |
| +- FrqGetUs
| |
| +- _SEXT16_32
| |
| +- _LDIVS_LC
| |
| +- _ENTER_BINARY_L_LC
| | |
| | +- _PUSH_ARGS_L
| |
| +- _LDIVS_k_is_k_div_j
| |
| +- _SPLITSIGN_L
| | |
| | +- _ABS_L_HX
| | |
| | +- _NEG_L_HX
| |
| +- _LDIVMOD
| |
| +- _NEG_L_HX (see above)
|
+- _Startup
|
+- Init
| |
| +- loadByte
|
+- main (see above)
_vect
|
+- _Startup (see above)
*********************************************************************************************
STATISTIC SECTION
---------------------------------------------------------------------------------------------
ExeFile:
--------
Number of blocks to be downloaded: 5
Total size of all blocks to be downloaded: 1933
>First of all, I cannot reproduce the warning.
Does this also mean that your app is now functioning?
From a quick look, it seems this version (which is not the same as your original) does not use floats at all.
int FrqGetUs(int frq){
So, maybe this explains why you no longer see a problem. Try adding a single float operation, and see if the problem re-appears. (Then, you know the culprit.)
At any rate, if with the current version you no longer see a problem, is there a reason to investigate it further?
Or are you still having a problem with the exact one you posted?
Sorry, no. We're again at that stage while debugger losts conection to target while debugging, but µc working in circuit. However, since it's not yet complete, it also fails in-circuit if I add two more for() loops. So the question was am I running out of memory and (where) can i figure out this (in project.map).
I don't use floats right now, but the respective library is still loaded. I dont want to try too many things at a time, finally not knowing what in detail had which effect. So it would be really helpful to know how much memory I use and to understand the changes if I use the integer library instead (If I would know that for instance, I have 1% Flash memory left with float and 2% with integer, I know that I need more than some cosmetic changes in order to fit the two remaining parts of code into the flash)
I don't have much time right now to examine everything in detail. I will have a better look sometime tomorrow. But, to help you get going by yourself a little bit...
If you look at your map, you will see a lot of lines that list
Section Name Size Type From To Segment
The From/To shows in hex what addresses each listed section occupies.
It also shows each subroutine etc where it is located. I can see that you use Flash from EC00 to FFFF.
EDITED: WAIT A MINUTE. That's a range of 5119. How's that possible? (I will check more tomorrow.)
And, finally, a summary indicating you only use 1933 bytes of Flash (R = ReadOnly memory).
Summary of section sizes per section type:
READ_ONLY (R): 78D (dec: 1933)
READ_WRITE (R/W): 30 (dec: 48)
NO_INIT (N/I): 27 (dec: 39)
So, code size does not seem to be your problem. I will have a better look tomorrow, and get back to you if I see something suspicious. I also tried to run you app in the simulator, but unfortunately the version of CW10 I have here (which, I don't use so I don't know it well enough) does not support HC08, only S08, so I wasn't able to test-run your code.
You don't need to hurry, I'm working on this since about two years or so, it's my free-evening-project, a day or a month doesn't care much :-)
But I appreciate any help I can find and I'm very pleased and thankful for your tips (i.e. now being able to figure out my code size).
I've attached pdeclaration.h as well as the device initialization code to the op.
I bet it should, cause it's not part of the project folder (however. I've CW 5.9 installed) I'm going to locate and attach it to the op as well.
If you private message me your email address, I could zip and send you the entire project folder as well - just in case...
Edit: Both attached to op
I will send it this evening when I'm back at home.
OK, technically, every language is eventually translated to machine code (which, because of its one-to-one correspondence with ASM, can be considered the same as saying to ASM). But, when we talk what language one uses we mean before the compiler does its job. Othewise, everybody would claim to be programming in assembly language, and there would be no mention of the higher level language.
"Address out of range" during the execution of what instruction? Can you see the disassembly (from your debugger) and post that? Also, please mention the exact MCU variant so we know what exactly we're dealing with.
Although I do all my MCU programming 100% in ASM, and my opinion could be viewed as biased by some, I would argue that, at least for the smaller memory devices (say, up to 8K Flash), programming in C is not the right approach, except for trivial apps. So, either get a bigger memory MCU, or switch this project to ASM.
Tony Papadimitriou schrieb:
But, when we talk what language one uses we mean before the compiler does its job. Othewise, everybody would claim to be programming in assembly language, and there would be no mention of the higher level language.
Ok for that, but that doesn't count when it is about the code size used in flash memory. I would love to code this in ASM, however it would take me years to finish since as I've learned 20 years ago, I found ASM kinda annoying. I admire everybody who can to this with ease.
If I recall correctly, this was a branch or jump instruction where that warning appeared. The device is MC68HC908JL3ECDWE. I will check for the debugger output later when I'm @home and will post the scourcecode as well. Its not a big thing, should become a control for rotary plate for 360° photography. Decodes a 10throw rotary switch, generates pulses for a stepmotor, two pushbuttons, two LEDs. It just misses the acceleration ramp and 48kHz modulated code output for infrared transmitter (camera remote).
Hi Tony,
Not wanting to hijack the thread but I was interested in your comment regarding not using C in smaller memory devices. Would you elaborate as to why you'd make this choice? I presume it's simply the overhead of C and coding more efficiently in assembler? While I'm also a big fan of assembler I would perhaps question how far one would go with it before switching to C.
Thanks,
Ian