- Sat Aug 30, 2014 6:52 pm
#56
Can anyone deal with the Chinese and build the IOT demo using the VMware image? It would be nice to know if everything builds. That would also give up something to compare to a build from gcc.
- Sat Sep 06, 2014 8:03 am
#248
I have loaded the resulting application binary (which I have uploaded here in the forum) to RAM using XTCOM_UTILITY.
after the IoT demo starts running, the following is repeated endlessly on the TX-Pin:
edit: I sacrificed one of my modules and flashed the resulting binary to the spi flash. but the excption printing remains
after the IoT demo starts running, the following is repeated endlessly on the TX-Pin:
Code: Select all
Fatal exception (28): <\r><\n>
epc1=0x40240430, epc2=0x00000000, epc3=0x00000000, excvaddr=0x006102fc, depc=0x00000000edit: I sacrificed one of my modules and flashed the resulting binary to the spi flash. but the excption printing remains
- Sat Sep 06, 2014 4:26 pm
#256
For clarification:
EPCx = Level-x exception program counter (the higher levels seem to have something to do with high-priority interrupts)
EXCVADDR = Exception virtual address
DEPC = Double exception program counter
EPC1 points to the offending instruction, while EXCVADDR seems to point to where the offending instruction referred to.
My guess is that the number in the brackets corresponds to an EXCCAUSE register value, which (obviously) indicates the cause of the exception.
Exception cause 28 (EXCCAUSE_LOAD_PROHIBITED) seems to indicate that you are running into trouble with the MMU: it does not allow a load from that address (which would not be strange, given it's outside 0x40000000 - 0x402fffff).
EPCx = Level-x exception program counter (the higher levels seem to have something to do with high-priority interrupts)
EXCVADDR = Exception virtual address
DEPC = Double exception program counter
EPC1 points to the offending instruction, while EXCVADDR seems to point to where the offending instruction referred to.
My guess is that the number in the brackets corresponds to an EXCCAUSE register value, which (obviously) indicates the cause of the exception.
Exception cause 28 (EXCCAUSE_LOAD_PROHIBITED) seems to indicate that you are running into trouble with the MMU: it does not allow a load from that address (which would not be strange, given it's outside 0x40000000 - 0x402fffff).
- Sat Sep 06, 2014 5:13 pm
#258
Hmm. Flashing may not be as simple as just burning said output file to the flash chip (or even worse, writing it to RAM directly): obviously, the memory addresses somehow have to be (re)mapped correctly. The files generated by genflashbinv6.exe are in some funky format, I'm not quite sure how suitable they are for direct flashing to anything.
If all is flashed/loaded properly, you should find BGEU a4, a6, 0x4024043b <wdt_init+0x287> (opcode 07b467) at position 0x40240430, which should IMHO not trigger such a fault (given it compares registers, and jumps to a location very nearby). You might want to check if you actually find this opcode at that address (or I guess actually 67 b4 07 due to endianness).
If all is flashed/loaded properly, you should find BGEU a4, a6, 0x4024043b <wdt_init+0x287> (opcode 07b467) at position 0x40240430, which should IMHO not trigger such a fault (given it compares registers, and jumps to a location very nearby). You might want to check if you actually find this opcode at that address (or I guess actually 67 b4 07 due to endianness).
