I haven't been able to reproduce this behaviour so far - I tried a BF533 example project (Booting (C)), enabled data cache and loaded it but the DCPLB_ADDR8 was always the register used for 0x01000000. This was the case for VisualDSP++ 5.0 Base Release, Update 5 and Update 7. Are you able to reproduce this with your project? If so, are you able to provide a copy of this project? If the information is of a sensitive nature, you can conteact us via Private support using the link below and include a link to this thread.

I think what you are noticing is a change that actually happened in Update 6. I recall you saying that you'd not gone to Update 6 in another thread so that would make sense. The changes release note entry is as follows:

Active CPLBs (Blackfin)All locked CPLBs will be loaded into the CPLB registers before any unlocked CPLBs, instead of just the first 16 as happened previously. Error labels too_many_locked_data_cplbs and too_many_locked_instruction_cplbs will indicate that there are at least 16 locked data or instruction cplbs, respectively, and additional cplbs will be locked out.

This change was in the _cplb_init function which takes the data tables that define the CPLB pages, dcplb_table and icplb_table and installes them into the CPLB MMRs registers if required depending on the definition of coltrol variable __cplb_ctrl.

The problem solved was that previously only the first 16 table entries were loaded and locked pages could therefore not be installed depending on where they were in the tables. Locked paged have to be installed first as they are presumed locked so that they are always accessible.

Unless you are setting bits in the CPLB MMRs registers directly, which we'd discourage you from doing, his change should not cause you any problems.