Hello,
I wrote a custom driver for the DTC and it has been running great, however at seemingly random points in the program the RL78 eventually ends up at address 0xFF0 with ?? (according to the disassembly in the IAR debugger) . Could this be because my linker files ram start address is 0xFBF00, and I don't offset my start address for the addresses below?
(RL78 F13/F14 user manual per Figure 3-14. Memory Map (R5F10AmG (m = G, L, M), R5F10BnG (n = A, B, G, L, M)))
From what I can tell my software is functioning fine and it's only when adding significantly more functionality that this becomes an issue. Currently I am only using my DTC driver for the simplified I2C peripheral and this works fine with fewer transactions. When attempting to send out more data this issue occurs sometimes as late as 900 seconds into the program runtime.
Thanks,
tempre
If the IAR linker file defines the RAM address to 0xFBF00 then this is wrong. The RAM on your device starts at 0xFDF00.
What exists on 0xFF0 ? Do you see what command exists on this line on the disassembly view ?
The areas you mentioned are reserved if the respective debugger functions are enabled, I do not think this is the cause of the problem.
Apologizes, I referenced the incorrect micro. This the correct micro with Figure 3-16. Memory Map (R5F10PmH (m = G, L, M, P)) with the correct RAM address start of 0xFBF00. There is no command in the disassembly view it's purely just followed by question marks (??) stopping/hitting a breakpoint any time prior to this occurrence results in a correct disassembly view. When it fails there is no assembly instruction on the disassembly just ??.
tempre said:From what I can tell my software is functioning fine and it's only when adding significantly more functionality that this becomes an issue.
This makes me think of a possible stack overflow. Have you tried to increase the stack size in the linker file ?
This was my original assumption, I increased the stack size from 200 --> 512 and the issue persisted, would you recommend further increasing it?
This sounds like a corrupted stack which causes a function's return-address to get clobbered. I don't know much about the "Stack Protection" feature of the IAR tools, but it might be worth a look.
You mentioned you wrote a custom driver for the DTC. Does that mean that you do not use the generated functions and configurations of DTC ?
One more question:
What is the source and destination area of DTC transfer ?
Hello, regarding your questions.
Yes I do not use the generated functions and configurations for the DTC. I do however follow them very closely. I am just using the DTC for reading and writing via simplified I2C. Here is exactly what I am doing in my I2CS DTC transfer driver
Write
Reads
Are all buffers initialized with a value ?
Yes, everything is initialized prior to kicking of the DTC (start watching for corresponded trigger)