RX63N download with RFP

Question

Hi, 
 I am using RX63N + E1 emulator + RFP V2.05 + CS+ and sw is dividing boot and application. 
 Boot use 0xFF7FC000 ~ 0xFF800000, a pplication use 0xFFF000 ~ 0xFFFFFFFF 
 Boot and application has each project. So mot files is made two(boot.mot, app.mot) 
 Boot and application has fixed vector table ( FFFFFF80h to FFFFFFFFh). 
 
 for example, 
 boot.mot 
 ~~~~~` 
 S315FFFFFFD0FF7FD540FF7FD548FF7FD548FF7FD542BF S315FFFFFFE0FF7FD548FF7FD544FF7FD548FF7FD548A5 S315FFFFFFF0FF7FD548FF7FD548FF7FD546FF7FC85098 
 ~~~~~ 
 app.mot 
 ~~~~~ 
 S315FFFFFFD0FFF54072FFF54077FFF5407CFFF5408167 S315FFFFFFE0FFF54086FFF5408BFFF54090FFF5409606 S315FFFFFFF0FFF5409CFFF540A2FFF540A8FFF0040088 
 ~~~~~ 
 E1 + RFP V2.05 didn't detect fixed vector's address overlapped. But RFP V3.0 above detect address overlapped and cannot download sw. 
 So I change boot's fixed vector address from 0xFFFFFF80 to 0xFF7FFFA0 and RFP V3.0 doesn't detect error and downloading is good. 
 As I know, fixed vector address is from 0xFFFFFF80 to 0xFFFFFFFF. 
 I have a question. 
 1. Can I change fixed vector address? 
 1) if right, could you share the document or sample code about this? 
 2) If wrong, could you tell me how do I fix this overlapped problem? 
 2. If two mot(boot.mot, app.mot) is merged, two mot's same address(boot's fixed vector address or app's ) has to be deleted. This is Am I right? 
 3. Does RFP V3.0 above has the ability to ignore overlapped problem? 
 4. In RFP setting, what is difference and advantage of using 'power target from the emulator' or not?

Thanks for your help in advance.

JimB · Answer

1.) The fixed vector table is FIXED. However, there is the relocatable vector table that can be used. Refer to the hardware user manual of the device for more information. 
 2.) The programming very much needs to flag the error of overlapping addresses when merging hex-files. The tool should not decide which piece of the overlap should be programmed (as what is undoubtedly happening with the older version of RFP) 
 3) No, and it should not provide such an option (see #2 above) 
 4) The option of the debugger providing power is available for convenience when external power is not provided. This works well with the simple reference boards that do not have many chip requiring power. As the power available from the debugger is limited, a custom design that exceeds this limit will require external power to be supplied.

Hossein · Answer

Hello dear JR, I&rsquo;m really sorry for the delay. 
 I&rsquo;ve gone through the issue and tried it on two different RX family MCU (RX231, 512KB ROM) and (RX66N, 4MB ROM) using CS+ IDE and CC-RX compiler, I&rsquo;ve attached project files at the end of the message. 
 Let&rsquo;s dive deeper into the hardware user&rsquo;s manual and see what happens when CPU starts 
 As you&rsquo;re familiar with branch operation and memory accessing, I try to explain it briefly (I hope I&rsquo;m not exhausting you): 
 
 -In RX63N, after a reset, CPU always branches to the address which resides in the &ldquo;0xFFFFFFFC&rdquo; 
 That&rsquo;s why we call it fixed vector table, there&rsquo;s no way to oblige the CPU to start off from any address other than 0xFFFFFFFC after a reset. 
 *Keep in mind that&rsquo;s a hardware constraint procedure, and we cannot compel CPU to change its RESET vector address, by changing sections addresses in compiler. (We can tell the compiler where we want to put the application and data within ROM, and where is the boundaries, but CPU decides to read the instructions from where) 
 *If you change the OUTPUT setup in your compiler to generate &ldquo;intel HEX file&rdquo; and look at it with a &lsquo;hex editor software&rsquo; you could clearly see the value in &ldquo;0xFFFFFFFC&rdquo; address is the address of &ldquo;PResetPRG&rdquo; section! so that CPU fetches the app&rsquo;s start address from &ldquo;0xFFFFFFFC&rdquo;. Now you can imagine what will happen if the value in that address were empty! (CPU will branch to a unknow address and app will not run). 
 My approach to run two individual apps on a RX device is: 
 -I divide Program ROM (0xFFE00000-0xFFFFFFFF) into two sections 
 Now in Application1: 
 -I don&rsquo;t modify &lsquo;FIXEDVECT&rsquo; section (let it be 0x0FFFFFFD0), and just change the &lsquo;PResetPRG&rsquo; section to a limited address in range of ROM capacity (!important! : the addresses must be a factor of 4) 
 -after handling all needed in application1, when it comes to Jumping to the application2. I&rsquo;ll use a branch instruction to the application2&rsquo;s RESETVECTOR (Which is a offset of 0x0FFFFFFD0)! 
 -extracting &lsquo;.mot or .hex&rsquo; file for programming 
 And in Application2: 
 -I modify the FIXEDVECT address (offset the 0x0FFFFFFD0 according to the application1 area), and change the &lsquo;PResetPRG&rsquo; to the &lsquo;0xFFE00000&rsquo;. 
 -Write the code as a normal application! 
 -extracting &lsquo;.mot or .hex&rsquo; file for programming 
 So and finally! We have no collision and RFP V3.0 will program two individual files successfully! 
 
 Your concerns might be: 
 
 1-What about Interrupts? What happens to interrupt ISRs after jumping to the app2? 
 2-What about app2 fixed vector? What will happen if we change that section in ROM? 
 3-What happens to non-maskable interrupts? 
 
 According to my experiment here&rsquo;s the answers: 
 1-there&rsquo;s a register in RX63N CPU which holds the address of the maskable interrupt table (INTB control register), as the reset value of that register is 0x0000000 by default, the application should take care of assigning a value to that register when initializing the hardware. 
 You should not be worried about this, the compiler takes care of that and produces the needed code according to the memory regions and ISR addresses. So even after Jumping to the app2 (Because of that we&rsquo;ve changed the fixed vector table, and the boundaries of two apps are different) the INTB value will dynamically change after a reset and maskable interrupts (Like Timer OVF) won&rsquo;t mess up with the app1&rsquo;s ISRs. 
 2-Although it&rsquo;s vital to not change the app1&rsquo;s fixed vector table area and we won&rsquo;t be able to run the MCU if there&rsquo;s no value in &lsquo;0xFFFFFFFC&rsquo;. But after booting up and running the app1, that won&rsquo;t be a problem anymore, we&rsquo;ll branch to the new fixed vector address of the app2, and that&rsquo;s like we&rsquo;ve swapped the app1 and app2 and performed a reset. 
 3-I&rsquo;m not sure if you&rsquo;re concerned about those type of interrupts, but as those are named fixed, even when we&rsquo;ve jumped into the app2, if the CPU throws a non-maskable interrupt, it will fetch the address of the ISRs in the app1! And that&rsquo;s like we&rsquo;re running app2, but app1&rsquo;s ISR functions are running (ISRs dedicated to the non-maskable interrupts). 
 In my opinion, that&rsquo;s not a big deal, you can write the app1&rsquo;s non-maskable ISR functions in a way that could handle errors in both apps (for example performing a reset!) 
 Even though, in some other devices like &lsquo;RX231&rsquo; and &lsquo;RX66N&rsquo; there&rsquo;s a control register just like INTB, which holds the address of exception vector table, and we can relocate it when jump to app2. 
 
 Here's the link of project examples that I worked on, you can check those projects and see the way that I wrote the code for both apps. 
 RX63N download with RFP issue.rar 
 I&rsquo;ve used two different LEDs, with different blink rates, which is connected to a timer interrupt, and used the same interrupt for both apps, so that assured me, there&rsquo;s no conflict in ISRs after jumping to the second app. 
 I hope I could provide you relevant information, don&rsquo;t hesitate to ask for clarification or follow up question. 
 Best regards. Hossein.

Hossein · Answer

Hi JR, 
 I&rsquo;m sorry for the problem with opening project files. I&rsquo;m using the latest CS+ version. By the way, you can check the .c files as plain text. Also, I have placed some text notes in the example project&rsquo;s directories which you might find useful. I have described it in detail (It addresses your questions). 
 But note that the RX66N and RX231, which I used to test, have different memory layouts. You should take a look at each Family hardware user&rsquo;s manual to understand the slight differences with RX63N. 
 About changing the project memory section areas in CS+ using CC-RX compiler, here are the steps: 
 
 You can determine the start address of the memory sections in your compiler. Then, the compiler will take care of the regions. *You might see a slightly different memory section layout if you&rsquo;re not using Smart Configurator. 
 
 I don&rsquo;t know how you were configuring the section addresses earlier, but that's the proper way to do it. 
 
 Regarding your questions:

&ldquo;In RX66N_Dual_APP2.rcpe, I found EXCEPTVECT/FFFF7EFF, RESETVECT/FFFF7FFC. Is that a modified address? If yes, when app2 is running, if an exception happens, does the program stop at the above address?&rdquo; 
 - Yes, that&rsquo;s the modified address, and yes, RX66N supports relocatable exception vector table address. But that&rsquo;s not the case in RX63N! In RX63N, when an exception happens, it always alludes to the app1 exception vector table and runs the code which is there (if it exists, and if not, stops).

About the areas of the provided examples, I recommend you to check the datasheet of each device and create a test project on your own. PResetPRG section specifies the upper bound of the program memory, so take care of overlapping addresses in your project for your RX63N device. (You can leave a section of memory reserved between two apps if you&rsquo;re afraid of overlapping sections.)

I have no idea about .mot file. I recommend you to build a .hex file and investigate it using hex editors (I use NeoHexEditor).

I hope I could explain it. Don&rsquo;t hesitate to ask questions if needed. 
 Best regards, Hossein. 
 JR said: 2) In map file, PResetPRG's address is 0xffff8000 in app1 and 0xffff0000 in app2. not 0xFFE00000.

Hossein · Answer

Dear JR, you might want to look at it from a different point of view, you mentioned "F ixed vector table must exist in one of two(app1 or app2) ". compiler creates binary files according to the section configuration which we've specified in the compiler setting in each project, so that both apps will have its fixed vector areas. (But app2's fixed vector area cannot be used directly by CPU, due RX63N limitation, but is defined virtually by the compiler) 
 after programming binary files, the app1 and app2 will occupy the memory in a determined way (the app 1 and app 2 are almost identical except the area which are placed in ROM. 
 We haven't changed the default vector table values of the app1 (we just limited the code section memory area of app1), thus the app1 will always run after each reset and will act like a normal application. the app1's behavior will be identical with a regular application. 
 but when it jumps to the app2 reset vector (which is somehow a virtual reset_vector), we'll have some problems with exception handling (if that's your concern). interrupt vector table will change dynamically after jumping to app2, but exception vector table won't be changed (in RX63N), and when an exception happens in app2 the CPU will refer to the exception vector of app1 (Although fixed vector table is specified virtually by compiler with an offset with app1's fixed vector table address). 
 
 Finally I recommend you not to be worried about exceptions in first stage, after setting up your application 
 you can dive deeper into the Rxv2 core user manual, and seek for instructions and exception handling in your application 
 
 Best regards, Hossein.