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?
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)
And the problem appears when the buffers are bigger ?
This problem only seems to appear with less time in between transfers, prior to this I would be transferring every 10ms. Now I am transferring data more frequently. I don't believe this is related to buffer size. I also believe JimB may be onto something. Certain actions result in the frequency changing. Such as reordering transfers, removing transfers, etc. Removing transfers makes this non reproduce able. I will check these transfers to see if there is anything problematic
Have you tried the high-speed transfer operation of DTC ?
The high-speed transfer can be realized by allocating the dedicated control data to the SFR area instead of the RAM area. To perform basic operation, normal mode requires five clock cycles to read vector and control data, while high-speed transfer requires one cycle. In addition, to write back control data, normalmode requires a maximum of three clock cycles, while high-speed transfer requires one cycle.