Bootloader打破USB堆栈

我首先要检查的是：1）引导加载程序和应用程序的配置字是否相同？如果它们没有加载到另一个上面，那么第一个加载的配置和固件中的某个地方就会出现故障。2）如果在引导加载程序和应用程序中使用一些PPS PIN映射，那么最好确保它们以相同的方式映射。激活多个PIN配置通道的PPS标志，否则第二个加载的应用程序将无法按照它想要的方式设置它的PIN。通常这个PPS锁是默认的…如果你需要像我一样的不同设置，那么你可以像我一样做：在引导加载程序中检查它是否被使用（PIN输入，RAM标记或类似）-如果它继续运行引导加载器，否则跳转到应用程序-当引导加载器是然后使用它在RAM中设置一个标记，它一直在执行，并进行软复位。在重置时，引导加载程序找到标记并跳转到应用程序，该应用程序可以任意设置它的PIN。



      以下为原文

    The first things I would check are:
1) Are the config words the same for the boot loader and the application?
If they are not then loading one on top of the other destroys the config for the first loaded and somewhere in the firmware there will be a failure.
 
2) If you are using some PPS pin mappings both in the boot loader and the application then you better make sure they are mapping the same way and also that the PPS flag for multiple pin configuration passes is activated.
Otherwise the second loaded application will not be able to set its pins the way it wants to. Normally this PPS lock is the default...
If you need different settings like I did then you may to do as I did:
- in the boot loader check if it is to be used (pin input, RAM marker or similar)
- if it is then continue to run the boot loader, otherwise jump to the application
- when the boot loader is used then at the end set a marker in RAM that it has been executing and make a soft reset.
  On reset the boot loader finds the marker and jumps to the application, which can set its pins any way it likes.
 
 
 

你好，鲍伯，谢谢你的回复。1）我把配置信息（所有的PrimaMac东西）放在一个共享的头文件中，应用程序和Bootloader首先包含在它们的主文件中，所以两者应该是相同的。2）这有点棘手，PPS可能是问题所在。我首先检查了在Bootloader中是否执行了PPS映射。我认为没有，除非它在USB库中有些模糊。我运行了RPor和RPIN的搜索，只在应用程序中找到它们。我注意到，我已经改变了它，尽管在引导加载程序中没有使用任何PPS，但我看不出它有什么不同。在这样做之后，我在没有链接器的情况下通过了我的应用程序，注意到OSCCONbits.IOLOCK在运行锁序列之后没有被设置：OLOCK位总是零。如果我将IOL1WORE重置为ON，则锁定序列将OsCONBIT.IOLoCK设置为1，但我注意到它在0启动，并且解锁序列不做任何事情。我在参考资料的印象中，IOL1WORD只是封锁了第二个解锁序列，但是它似乎只是把iOLoCK保持到0，所以永远不需要解锁。无论如何，我认为测试IOL1WORE = OFF是最好的设置，在这个设置中，我仍然有同样的问题。我只想把它搁置，直到我能找到解决陷阱的方法。



      以下为原文

    Hi Bob, 
    Thanks for replying.   
1)   I put the config info (all the pragma stuff) in a shared header file that both application and bootloader include first in their main files, so both should be identical.
2)   This is a bit trickier and maybe PPS is the issue.  I first checked if i did any PPS mapping in the bootloader.  I don't think there is, unless it's obfuscated some how in the USB libraries.  I ran a search for RPOR and RPIN and only found them in the application.  I did notice that I had #pragma config IOL1WAY = ON 
and have changed it to #pragma config IOL1WAY = OFF , although without using any PPS in the bootloader, i can't see it making a difference.
After doing that, i stepped through my application built without the linker and noticed that OSCCONbits.IOLOCK is not being set after running the lock sequence:

 
__builtin_write_OSCCONL(OSCCON & ~(1<<6)); //Unlock Registers
RPOR4bits.RP9R = 8;; /*set rp9 as sck1 (output)*/
RPOR7bits.RP14R = 7; /*set rp14 as sdo1 (output)*/
RPINR20bits.SDI1R = 6; /*set rp6 as sdi1 (input)*/
RPINR19bits.U2RXR = 25; //U2RX on pin 66 RD4 RP25
RPOR10bits.RP20R = 5;//U2TX on pin 67 RD5 RP20
__builtin_write_OSCCONL(OSCCON | (1<<6)); // Lock Registers
 

 
The IOLOCK bit is always zero.  If i reset IOL1WAY to ON, the lock sequence sets OSCCONbits.IOLOCK to 1, but i notice it boots at 0, and the unlock sequence doesn't do anything.  I was under the impression from the reference materials that IOL1WAY just blocked a second unlock sequence, but it appears that it just holds IOLOCK to 0 always so no unlock is ever required.  
 
Anyway, I think for testing IOL1WAY = OFF is the best setting, and in this setup, I am still getting the same problem.  I'm just going to leave it off until I can find a solution to my trap issues.

你的IVT是否正确处理？其他ISRS工作吗？Bootloader是否留下任何中断启用标志集？



      以下为原文

    Is your IVT correctly handled?
are other ISRs working?
does the Bootloader leave any Interrupt enable flags set?

我不能说链接器文件中的IVT设置是100%，因为我刚刚从旧的MAL中取得了主机引导加载程序，但是，我可以说，我确实使用T1、T3、T45和RTCC中断而没有问题。下面是引导加载程序结束时使用的代码。USB有自己的中断设置有点奇怪，包括写“1”清除U1IR，但纠正我如果我错了：我只是检查，当我插入一个USB闪存驱动器，中断是由应用程序ISR，USb1中断在UBSHOST主机。C，也检查CN，RTCC，T1中断实际上是红色。根据我对IVT和重新映射的理解，如果它不正确，中断将无法向应用程序ISR进行矢量化。我认为这是正确的，只要链接器是一致的，但我不知道什么我不知道。



      以下为原文

    I cannot say the IVT setup in the linker files is 100% as I just took it from the old MAL that had the host bootloader, however, I can say that I do use T1, T3, T45 and RTCC interrupts without issue.  Here is the code used at the end of the bootloader.  USB having it's own interrupt set is a bit weird, including the write '1' to clear on U1IR, but correct me if I'm wrong:
 

 
 
 
USBHostShutdown();
//Disable USB interrupts
U1IE = 0;
U1IR = 0xFF; //write '1' to clear these (DS39897C-page 234)

//Disable other interrupts
IEC0 = 0;
IEC1 = 0;
IEC2 = 0;
IEC3 = 0;
IEC4 = 0;
IEC5 = 0;

IFS0 = 0;
IFS1 = 0;
IFS2 = 0;
IFS3 = 0;
IFS4 = 0;
IFS5 = 0;

_ALTIVT = 0; //switch to std interrupt vectors
BootApplication(); //Launch App, there will be no code from BL run after this
 
 
 

 
 I just checked that when I insert a u*** flash drive, the interrupt is handled by the apps ISR, _USB1Interrupt in u***_host.c.  also checked CN, RTCC, T1 interrupts are actually entered.  From my understanding of the IVT and the remapping, if it were incorrect, the interrupt would not be able to vector to the apps ISR.  I think it's correct as far as the linker is concered, but I don't know what I don't know.