Har två arrays
const unsigned char arrayX[]={byte1, byte2,,,,,,,,,,,,,,};
Array1 3584 bytes
Array2 4570 bytes
kompilering/länkning/programmering funkar felfritt.
När man sedan kör händer ingenting, dock tror MPLAB att det snurrar som det skall.
när man pausar/stoppar exekveringen får man ingen indikation vilken kodrad som skall köras, inte ens i disassembly-listningen.
inga exeptions indikeras.
Om man reducerar någon av arrayerna till hälften, typ, funkar saker som det skall.
Kompilator/ICD Fel, stora const arr krachar PIC32/C32 [LÖST]
Kompilator/ICD Fel, stora const arr krachar PIC32/C32 [LÖST]
Senast redigerad av TomasL 17 februari 2012, 16:19:40, redigerad totalt 1 gång.
Re: stora constant arrays krachar MCC32/PIC32
Jag vet inte ett smack om detta, men hur ser det ut på
alla "vanliga" ställen? Listfiler och mapfiler t.ex. Något som
avviker mot de halva arrayerna t.ex.
"const" arrayer ska alltså allokeras i flash, antar jag.
Men för övrigt håller jag helt med johano...
alla "vanliga" ställen? Listfiler och mapfiler t.ex. Något som
avviker mot de halva arrayerna t.ex.
"const" arrayer ska alltså allokeras i flash, antar jag.
Men för övrigt håller jag helt med johano...
Re: stora constant arrays krachar MCC32/PIC32
En gissning är att FLASH-sidorna i processorn är 8k, och att när summan av din data blir större än 8k går någonting fel. Det kanske går att lösa med något #pragma som sätter arrayerna i varsin FLASH-sida.
Re: stora constant arrays krachar MCC32/PIC32
Minnesallokeringen är om jag förstått "best fit" eller .rosdata.
dock finns det ingen direkt sammaställning i map-filen.
Ja, konstanter tenderar att hamna i programminnet.
men här kommer lite dissasembly
Det verkar som vi hamnat i en bootstrap exception
dock finns det ingen direkt sammaställning i map-filen.
Ja, konstanter tenderar att hamna i programminnet.
men här kommer lite dissasembly
Det verkar som vi hamnat i en bootstrap exception
Kod: Markera allt
Line Address Virtual Opcode Label Disassembly
Starts here
163843 Boot Flash Memory
163844 1FC0_0000 BFC0_0000 3C1ABFC0 lui k0,0xbfc0
163845 1FC0_0004 BFC0_0004 275A0010 addiu k0,k0,16
163846 1FC0_0008 BFC0_0008 03400008 jr k0
163847 1FC0_000C BFC0_000C 00000000 nop
163848 1FC0_0010 BFC0_0010 401A6000 mfc0 k0,Status
163849 1FC0_0014 BFC0_0014 7F5A04C0 ext k0,k0,19,1
163850 1FC0_0018 BFC0_0018 13400005 beq k0,zero,0x1fc00030
163851 1FC0_001C BFC0_001C 00000000 nop
163852 1FC0_0020 BFC0_0020 3C1A9D01 lui k0,0x9d01
163853 1FC0_0024 BFC0_0024 275A8868 addiu k0,k0,-30616
163854 1FC0_0028 BFC0_0028 03400008 jr k0
163855 1FC0_002C BFC0_002C 00000000 nop
163856 1FC0_0030 BFC0_0030 3C1DA002 lui sp,0xa002
163857 1FC0_0034 BFC0_0034 27BDFFF8 addiu sp,sp,-8
163858 1FC0_0038 BFC0_0038 3C1CA001 lui gp,0xa001
163859 1FC0_003C BFC0_003C 279C81F0 addiu gp,gp,-32272
163860 1FC0_0040 BFC0_0040 40096002 mfc0 t1,SRSCtl
163861 1FC0_0044 BFC0_0044 01205820 add t3,t1,zero
163862 1FC0_0048 BFC0_0048 7D2A1E80 ext t2,t1,26,4
163863 1FC0_004C BFC0_004C 7D494984 ins t1,t2,6,4
163864 1FC0_0050 BFC0_0050 40896002 mtc0 t1,SRSCtl
163865 1FC0_0054 BFC0_0054 000000C0 ehb
163866 1FC0_0058 BFC0_0058 41DCE000 wrpgpr gp,gp
163867 1FC0_005C BFC0_005C 408B6002 mtc0 t3,SRSCtl
163868 1FC0_0060 BFC0_0060 3C089D01 lui t0,0x9d01
163869 1FC0_0064 BFC0_0064 2508890C addiu t0,t0,-30452
163870 1FC0_0068 BFC0_0068 0100F809 jalr ra,t0
First jump here
41532 1D00_88E4 9D00_88E4 BF805000 cache 0x0,20480(gp)
41533 1D00_88E8 9D00_88E8 BF805100 cache 0x0,20736(gp)
41534 1D00_88EC 9D00_88EC BF805200 cache 0x0,20992(gp)
destination jump 1
41535 1D00_88F0 9D00_88F0 0F40179D jal 0x1d005e74
41536 1D00_88F4 9D00_88F4 00000000 nop
41537 1D00_88F8 9D00_88F8 1000FFFF beq zero,zero,0x1d0088f8
41538 1D00_88FC 9D00_88FC 00000000 nop
Loops here
41539 1D00_8900 9D00_8900 7000003F _bootstrap_exception_handler sdbbp 0x0
41540 1D00_8904 9D00_8904 0B402241 j 0x1d008904
second jump here
41541 1D00_8908 9D00_8908 00000000 nop
41542 1D00_890C 9D00_890C 03E00008 _on_reset jr ra
41543 1D00_8910 9D00_8910 00000000 nop
41544 1D00_8914 9D00_8914 03E00008 _on_bootstrap jr ra
41545 1D00_8918 9D00_8918 00000000 nop
41546 1D00_891C 9D00_891C 03E00008 INTDisableInterrupts jr ra
41547 1D00_8920 9D00_8920 41626000 di v0
41548 1D00_8924 FFFFFFFF sd ra,-1(ra)
41549 1D00_8928 FFFFFFFF sd ra,-1(ra)
164064 1FC0_0370 FFFFFFFF sd ra,-1(ra)
164065 1FC0_0374 FFFFFFFF sd ra,-1(ra)
164066 1FC0_0378 FFFFFFFF sd ra,-1(ra)
164067 1FC0_037C FFFFFFFF sd ra,-1(ra)
destination jump 2
164068 1FC0_0380 BFC0_0380 3C1A9D01 lui k0,0x9d01
164069 1FC0_0384 BFC0_0384 275A8900 addiu k0,k0,-30464
164070 1FC0_0388 BFC0_0388 03400008 jr k0
Loops back
164071 1FC0_038C BFC0_038C 00000000 nop
164072 1FC0_0390 FFFFFFFF sd ra,-1(ra) Re: stora constant arrays krachar MCC32/PIC32
Lite mer info.
Vi la till en lite bättre exception_handler och fick följande
För de som är intresserade så bifogar jag mapfilerna från en fungerande kompilering ( där vi reducerat arrayerna) och en där arrayerna har full storlek.
Ingen av adresserna som pekas ut av epc eller badvaddr existerar, varken som virtuell eller fysisk, däremot finns de som unikt innehåll på varsin adress.
exception handlern ser ut så här
Vi la till en lite bättre exception_handler och fick följande
Kod: Markera allt
_excep_code = EXCEP_RI // reserved instruction
epc = 0xBFC00000
badvaddr = 0xFCFC4D7FIngen av adresserna som pekas ut av epc eller badvaddr existerar, varken som virtuell eller fysisk, däremot finns de som unikt innehåll på varsin adress.
exception handlern ser ut så här
Kod: Markera allt
void _general_exception_handler(unsigned cause, unsigned status) {
unsigned epc = _CP0_GET_EPC();
unsigned badvaddr = _CP0_GET_BADVADDR();
while(1);
}
static enum {
EXCEP_IRQ = 0, // interrupt
EXCEP_AdEL = 4, // address error exception (load or ifetch)
EXCEP_AdES, // address error exception (store)
EXCEP_IBE, // bus error (ifetch)
EXCEP_DBE, // bus error (load/store)
EXCEP_Sys, // syscall
EXCEP_Bp, // breakpoint
EXCEP_RI, // reserved instruction
EXCEP_CpU, // coprocessor unusable
EXCEP_Overflow, // arithmetic overflow
EXCEP_Trap, // trap (possible divide by zero)
EXCEP_IS1 = 16, // implementation specfic 1
EXCEP_CEU, // CorExtend Unuseable
EXCEP_C2E // coprocessor 2
} _excep_code;
static unsigned int _epc_code;
static unsigned int _excep_addr;
void _bootstrap_exception_handler(unsigned cause, unsigned status) {
asm volatile("mfc0 %0,$13" : "=r" (_excep_code));
asm volatile("mfc0 %0,$14" : "=r" (_excep_addr));
_excep_code = (_excep_code & 0x0000007C) >> 2;
unsigned epc = _CP0_GET_EPC();
unsigned badvaddr = _CP0_GET_BADVADDR();
while(1);
}Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: stora constant arrays krachar MCC32/PIC32
Sådär, nu är det ännu mera konstigheter.
Enligt MPLAB händer detta i processorn:
Med följande registervärden:
Vad man kan se är att när hopp 3 exekveras på rad 41889, så borde man hamna på den adressen som ra pekar ut (0xBFC00070), istället hamnar man på BFC0_0380.
Såsom jag fattat det så skall "jr ra" instruktionen hoppa till adressen lagrad i ra registret, ingen annanstans, men uppenbarligen så hoppas det till en helt annan del av minnet, vilket i sin tur skapar hoppet till boot_exception
Enligt MPLAB händer detta i processorn:
Kod: Markera allt
Line Address Virtual Opcode Label Disassembly
163843 Boot Flash Memory
-->
163844 1FC0_0000 BFC0_0000 3C1ABFC0 lui k0,0xbfc0
163845 1FC0_0004 BFC0_0004 275A0010 addiu k0,k0,16
163846 1FC0_0008 BFC0_0008 03400008 jr k0
163847 1FC0_000C BFC0_000C 00000000 nop
163848 1FC0_0010 BFC0_0010 401A6000 mfc0 k0,Status
163849 1FC0_0014 BFC0_0014 7F5A04C0 ext k0,k0,19,1
163850 1FC0_0018 BFC0_0018 13400005 beq k0,zero,0x1fc00030 ---- 1 -->
163851 1FC0_001C BFC0_001C 00000000 nop
163852 1FC0_0020 BFC0_0020 3C1A9D01 lui k0,0x9d01
163853 1FC0_0024 BFC0_0024 275A8DE0 addiu k0,k0,-29216
163854 1FC0_0028 BFC0_0028 03400008 jr k0
163855 1FC0_002C BFC0_002C 00000000 nop
--- 1 --->
163856 1FC0_0030 BFC0_0030 3C1DA002 lui sp,0xa002
163857 1FC0_0034 BFC0_0034 27BDFFF0 addiu sp,sp,-16
163858 1FC0_0038 BFC0_0038 3C1CA001 lui gp,0xa001
163859 1FC0_003C BFC0_003C 279C81F0 addiu gp,gp,-32272
163860 1FC0_0040 BFC0_0040 40096002 mfc0 t1,SRSCtl
163861 1FC0_0044 BFC0_0044 01205820 add t3,t1,zero
163862 1FC0_0048 BFC0_0048 7D2A1E80 ext t2,t1,26,4
163863 1FC0_004C BFC0_004C 7D494984 ins t1,t2,6,4
163864 1FC0_0050 BFC0_0050 40896002 mtc0 t1,SRSCtl
163865 1FC0_0054 BFC0_0054 000000C0 ehb
163866 1FC0_0058 BFC0_0058 41DCE000 wrpgpr gp,gp
163867 1FC0_005C BFC0_005C 408B6002 mtc0 t3,SRSCtl
163868 1FC0_0060 BFC0_0060 3C089D01 lui t0,0x9d01
163869 1FC0_0064 BFC0_0064 25088E78 addiu t0,t0,-29064
163870 1FC0_0068 BFC0_0068 0100F809 jalr ra,t0 ----- 2 --->
163871 1FC0_006C BFC0_006C 00000000 nop
163872 1FC0_0070 BFC0_0070 3C08A000 lui t0,0xa000
163873 1FC0_0074 BFC0_0074 2508020C addiu t0,t0,524
163874 1FC0_0078 BFC0_0078 3C09A000 lui t1,0xa000
163875 1FC0_007C BFC0_007C 25290334 addiu t1,t1,820
163876 1FC0_0080 BFC0_0080 10000006 beq zero,zero,0x1fc0009c
163877 1FC0_0084 BFC0_0084 00000000 nop
Line Address Virtual Opcode Label Disassembly
---------------------------------------------------------------------------------
41884 1D00_8E64 9D00_8E64 BF805200 cache 0x0,20992(gp)
41885 1D00_8E68 9D00_8E68 0F40194E jal 0x1d006538
41886 1D00_8E6C 9D00_8E6C 00000000 nop
41887 1D00_8E70 9D00_8E70 1000FFFF beq zero,zero,0x1d008e70
41888 1D00_8E74 9D00_8E74 00000000 nop
--- 2 --->
41889 1D00_8E78 9D00_8E78 03E00008 _on_reset jr ra --- 3 --->
41890 1D00_8E7C 9D00_8E7C 00000000 nop
41891 1D00_8E80 9D00_8E80 03E00008 _on_bootstrap jr ra
41892 1D00_8E84 9D00_8E84 00000000 nop
41893 1D00_8E88 9D00_8E88 03E00008 INTDisableInterrupts jr ra
--- 3 --->
164068 1FC0_0380 BFC0_0380 3C1A9D00 lui k0,0x9d00
164069 1FC0_0384 BFC0_0384 275A64EC addiu k0,k0,25836
164070 1FC0_0388 BFC0_0388 03400008 jr k0 ----> _bootstrap_exception_handler
164071 1FC0_038C BFC0_038C 00000000 nop Kod: Markera allt
---------Registers--------------
Name Hex Decimal
BadVAddr 0xFCFC4D7F 4244393343
Cause 0x10800028 276824104
Compare 0xFFFFFFFF 4294967295
Config 0xA4210582 2753627522
Config1 0x80000006 2147483654
Config2 0x80000000 2147483648
Config3 0x00000160 352
Count 0x0000005A 90
DEPC 0x9D0064EC 2634048748
DESAVE 0x00000000 0
Debug 0x40118001 1074888705
Debug2 0x00000000 0
EBASE 0x80000000 2147483648
EPC 0xBFC00000 3217031168
ErrorEPC 0xBFC024E4 3217040612
HWREna 0x00000000 0
IntCtl 0x00000000 0
PRId 0x00018765 100197
SRSCtl 0x04000000 67108864
SRSMap 0x00000000 0
Status 0x00500006 5242886
TraceBPC 0x00000000 0
TraceControl 0x00000000 0
TraceControl20x00000000 0
UserTraceData0x00000000 0
a0 0x00000000 0
a1 0x00000000 0
a2 0x00000000 0
a3 0x00000000 0
at 0x00000000 0
fp 0x00000000 0
gp 0xA00081F0 2684387824
hi 0x00000001 1
k0 0x9D0064EC 2634048748
k1 0x00000000 0
lo 0x00000001 1
ra 0xBFC00070 3217031280
s0 0x00000000 0
s1 0x00000000 0
s2 0x00000000 0
s3 0x00000000 0
s4 0x00000000 0
s5 0x00000000 0
s6 0x00000000 0
s7 0x00000000 0
sp 0xA001FFF0 2684485616
t0 0x9D008E78 2634059384
t1 0x04000040 67108928
t2 0x00000001 1
t3 0x04000000 67108864
t4 0x00000000 0
t5 0x00000000 0
t6 0x00000000 0
t7 0x00000000 0
t8 0x00000000 0
t9 0x00000000 0
v0 0x00000000 0
v1 0x00000000 0
zero 0x00000000 0Såsom jag fattat det så skall "jr ra" instruktionen hoppa till adressen lagrad i ra registret, ingen annanstans, men uppenbarligen så hoppas det till en helt annan del av minnet, vilket i sin tur skapar hoppet till boot_exception
Re: stora constant arrays krachar MCC32/PIC32
Har du testat på Microchips forum, eller direkt med Microchip?
Re: stora constant arrays krachar MCC32/PIC32
Ja, men svaren lyser liksom med sin frånvaro, på gott och ont, nej har inte kontaktat supporten än.
Gissar att jag får göra det.
Gissar att jag får göra det.
Re: LÖST, Kompilator/ICD Fel, stora const arr krachar PIC32/
Så nu har vi äntligen lyckats lösa problemet, det visade sig finnas en liten fullständigt livsfarlig inställning för ICD'n, vilken bästämmer vilket minnesområde ICD'n skall arbeta inom.
Av någon annledning, förmodligen har MPLAB hittat på detta själv, så var minneshanteringen ändrad från automatisk till manuell, och av någon outgrundlig anledning så defaultar det till det området som användes senast den stod i automatiskt läge.
Av någon annledning, förmodligen har MPLAB hittat på detta själv, så var minneshanteringen ändrad från automatisk till manuell, och av någon outgrundlig anledning så defaultar det till det området som användes senast den stod i automatiskt läge.
