Register tests for V850 port using MINICUBE2

I try to make freeRTOS v7.1.1 work on V850ES/Jx3-L low-power demonstrator (http://am.renesas.com/products/tools/introductory_evaluation_tools/renesas_demo_kits/v850es_jx3l_lpd/index.jsp). I debugged the following code snippet  excerpted from the register test code (RegTest.s85) using MINICUBE2 and found that R31’s content is always 0x0. My question is anybody has verified freeRTOS’s V850 port on any hardware?
MOV 0xa101010b, R31
CMP R31, R1
BZ $+6
JARL vRegTestFailed, lp

Register tests for V850 port using MINICUBE2

In the code snippet you have posted, you are setting the value of R31, then testing the value of R31, all done in assembly code so the compiler cannot be interfering.  If, after setting the value of R31 it does not hold the value you just wrote to it, then there is something strange going on indeed.  Please not however, that this code is not part of the FreeRTOS code, it is just assembly code in the application.  It could be feasible that an interrupt is occurring between setting R31 and testing R31, and that that interrupt is corrupting R31.  To discount that try disabling interrupts in the asm code before the MOV instruction.  It could also be feasible that the trap instruction before the MOV instruction (not shown in your code snippet) is causing the MOV to get skipped somehow – try adding a couple of NOP instructions between the TRAP and the MOV instructions. That said… The code in the FreeRTOS download is different to the code you posted in that the value written to R31 has changed.  This is the code in the download:
    MOV     0x01010101, R31
    CMP     R31, R1
    BZ      $+6
    JARL    vRegTestFailed, lp
What else did you change?  Did you also change the value in R1 to match? Regards.

Register tests for V850 port using MINICUBE2

Richard, Thank you very much for your reply. Actually, the code I quoted is from the second register test routine and yours is from the first one. They stored different values in R1 register. I commented out TRAP instruction because it stopped the debugger from functioning. I think the reason causing the problem is because the on-chip monitor program downloaded by debugger uses interrupt and function calls. In order to using the debug function, I didn’t disable the general interrupt mask using DI instruction. Instead, I just masked the tick timer interrupt. Charles