Thanks Francis for your reply!
I understand that maybe code banking is not the top choice for most upsd users, but U should admit that at this moment ride can improve a lot the code banking handling.
In effect PLM mode was not useful for me, 'cause I should use both code banking AND printf/sprintf functions, and I suppose this is the case of most upsd+code banking users; as stated, the user in this situation should dig into assembly code to solve the problem.
The "conflict when exploring code" was appearing after programming from Raisonance IDE the upsd flash and running the program; in this case the flash programming seems to be different from what was expected, the program runs out of control, U cannot stop it with breakpoints.
I have controlled the register window and I was suspecting the ride was programming the flash using the previous non-banked flash files, but also after a complete cleanup the conflict was not solved.
Really: I cannot ignore the conflict message, because I was unable to run/debug/test the program! Also stopping the program was requiring a lot of time, with the message appearing "Step not over yet, go on?". Why did the code merged and programmed from psdsoft runs ok, and the same code programmed from ride not?
Anyway, I think it would be very useful if, in a future release, eg:
- a correct and exhaustive a51 file for code banking was supplied with the ride kit
- when U place a breakpoint on a line of banked code, the program won't stop also when executing an instruction on same code offset, but different page
- the correspondance between module and bank is easier to set; now U should enter project-linker-code banking-modules-scroll the module list...
- also the asm/endasm pragmas was powered; at this time, U loose sync on debug information on the files with src control, and also on all the consecutive modules...
- when U change one project options, this action don't reset also all of the local options set on the module project files: this is a very boring bug
- U can dump on disk noth registers and memory
- when upsd34xx is selected as target, the "use external stack" option is automatically disabled and grayed

Best regards
Michele

Thanks for this report. We will clean up these items.

It's a while since I've been here, so this is a late reply.

I've been around the all same problems and concluded that the debugger was simply incompatible with banking. I ended up writing my own banking system specifically for uPSD, which also runs within the confines of the 32k limitations of RKit-Lite (uPSD can't usefully run banks bigger than 32k anyway). I don't know whether it is deliberate or a bug, but as well as limiting code to 32k, Lite also blocks compiling or linking to any addresses above 32k..

I implemented (most of ) a USB flash disk with fscanf etc. Yes, both data AND program in the big flash. I put this module in one (slave) bank and my 'user' application in the main bank. I got around the debugger problems by recompiling the slave bank as a single bank program with a stub main program as a separate project, and just switched projects when I had to chase a bug in the slave bank. Yes it still occasionally hits breakpoint addresses while running in the slave bank, but it's pretty obvious when it does, (keep an eye on the stack dump, and just check the page register if in doubt) and it's easy to recompile the bank with the offending code moved out of the way.

I don't think anyone ever explained what is going on when the machine seems to freeze and says "step not yet over". It seems that after a stop command, Ride single-steps the processor trying to get to the end of a line of the C code. If the processor is not executing the code Ride thinks it is, eg a page change or stack corruption, then this goes on forever and Ride times it out. At least that's how I figure it.

Tim Jackson

The problems reported by 'technico27' had been fixed (current version).
For the last message from Tim (Puposet), yes it is normal that bank switching does not work with the 32K version (at least for compiling/linking). I tested bank switching on a Raisonance 'bank-switching' project, and it works. I don't know if it works with several programs located into different banks.
For the 'step not yet over': yes, we use breakpoint for stepping at the C level, but when there is no more available breakpoint, we single-step at the assembly level. For extra-bank calls (a call from a bank to another bank), single-stepping could be quite long..

Hi Francis, i tried to install the update, but the linker won't find the floating point library...
Maybe it has installed the limited version? Can I install this update?

I've seen that in the ride\lib directory the RC51FPL.LIB file is only 1k size.
I am using large memory model with ieee floating point.
Anyway I can continue working with the old ride toolchain...