Bootloader Questions - (CAN)

John Westmoreland43

Hello - maybe this should be directed to QJ -

When using the bootloader code on both the host and processor - if a large bootfile is downloaded - of course more space is needed to download the file from the host system and that is allocated on the host side.

For the processor side; for a larger file - let's just say 160K - the download will run - but somewhere along the way a message gets printed that the part is programmed but the bootloader is still downloading data and isn't finished. It looks like all of the counters; sizeof's and all of that is OK - but there looks like there is a bug here. I will try to catch this but wanted to mention what I am seeing.

Has anyone encountered this problem?

I have been able to download the 'blinky' application OK - but it is rather small - only about a 4KB binary file. It would be nice to see the linker command file for that. I assume the biggest issue is to make sure the starting address in FLASH for the downloaded program is 0x20000 and also not to assign any RAM from what the bootloader needs. I have done that but since the program isn't ever loaded I am not really getting to that point.

I am wondering if there could be a sync problem between when the bootloader code is/was released and the F021 API. I haven't looked closely enough yet to see if there are issues like going past a 64K boundary or anything like that - but I will look.

Regards,
johnw

over 10 years ago

0 John Westmoreland43 over 10 years ago

Guru 13915 points

The 02.01.01 stuff was installed - but in the project on the processor side - under the F021_API dir - those files are v2.00.01 Build(000824).
So, that needs to be synced manually.

0 KARTHIKEYAN RAJAMANICKAM over 10 years ago in reply to John Westmoreland43

TI__Genius 11645 points

Johnw,

If you are already in touch with QJ on email, can we close this thread ? Thanks.

0 John Westmoreland43 over 10 years ago in reply to KARTHIKEYAN RAJAMANICKAM

Guru 13915 points

Karthik,
It looks like we may have found a bug - don't you think others will want to know how this is resolved?
Regards,
John W.

0 KARTHIKEYAN RAJAMANICKAM over 10 years ago in reply to John Westmoreland43

TI__Genius 11645 points

John,

Certainly yes.

If possible then pls post the details/summary on this thread once you guys finalize the issue.

0 John Westmoreland43 over 10 years ago in reply to KARTHIKEYAN RAJAMANICKAM

Guru 13915 points

Hello Karthik,

We have verified the bug exists in both the CAN and SPI builds. We are still working on it/testing.

Regards,
John

0 KARTHIKEYAN RAJAMANICKAM over 10 years ago in reply to John Westmoreland43

TI__Genius 11645 points

Thanks John.

Pls drop a line on this thread once you guys are done.

0 John Westmoreland43 over 10 years ago in reply to KARTHIKEYAN RAJAMANICKAM

Guru 13915 points

Hello TI/Karthik,

QJ and I have verified the bug is fixed - ulOffset in the Host code was declared to be unsigned short vs. unsigned long.

Note, once this is fixed there are other functions that will complain - u16's vs. longs - that has to be fixed too. (On the Host side.)

QJ is using the NI I/F for CAN - I am using the Komodo DUO - since I did that port - no complaints re: u16 vs. ul after the fix - but for the SPI -
Aardvark - those need to be fixed.

The SPI and CAN bootloaders are running both on the host and processor sides OK after the fix(es).

So, this bug can be closed - if TI has a QA dept. that looks at these issues - would be a great idea for them to log into something like Bugzilla and note all of the updates and to rev and post the fixed code - just a suggestion.

Thanks and Regards,
John W.

0 KARTHIKEYAN RAJAMANICKAM over 10 years ago in reply to John Westmoreland43

TI__Genius 11645 points

Thanks John.

I'll drop a line to QJ on this.

0 John Westmoreland43 over 9 years ago in reply to KARTHIKEYAN RAJAMANICKAM

Guru 13915 points

Hello All,

I have been looking at some processor side issues with the bootloader code - and am finding some similar issues:

bl_main.c:

uint32_t g_pulUpdateSuccess[] = {0x5A5A5A5A, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};

uint32_t g_ulUpdateStatusAddr = 0x07FC0;

uint32_t g_ulVectorTable = 0x8000000;

uint32_t g_ulUpdateBufferSize = 32; //32 bytes or 8 32-bit words

bl_check.c:

extern unsigned long g_pulUpdateSuccess[8];

extern unsigned long g_pulUpdateFail[8];

extern unsigned long g_ulUpdateStatusAddr;

bl_ymodem.c:

oReturnCheck = Fapi_BlockProgram( updateStatusBank, g_ulUpdateStatusAddr, (unsigned long)&g_pulUpdateSuccess, g_ulUpdateBufferSize); - which is different than the declaration

Just wondering what the intent was in coding this way.

Thanks,
johnw

Arm-based microcontrollers

Arm-based microcontrollers forum

Bootloader Questions - (CAN)