SparkFun Forums

[az83]

Yup, I don't have a problem with the Synchronized part.

By the way, you mentioned about no CRC value inserted at 0x14 - how can I get more information on this? I am not aware that I need that CRC value at that particular location.

As for the memory map, can I presume that the memory map presented in the datasheet should tally with that written in the software code?

Thanks once again!

[viskr]

Information on the CRC is in the NXP user manuals, as I vaguely remember its on the first 32 vectors

You could also download our GCC tools, they are not setup for the 1768, but if you set it to 1756 it will compile and load code to get started (its a subset memory wise). To make them work for the 1768 would require some minor edits to the linker .ld file

http://www.coridium.us/files/setupC.exe

[az83]

I decided to compare my generated hex file and the memory that I have just programmed. My generated hex file looks somewhat like this:

Code: Select all

:102000000808001019210000000000000000000076
:10201000152100001521000015210000000000001E
:10202000000000000000000000000000152100007A
:1020300015210000000000001521000015210000FE
:1020400015210000152100001521000015210000B8
:1020500015210000152100001521000015210000A8
:102060001521000015210000152100001521000098
:102070001521000015210000152100001521000088
:102080001521000015210000152100001521000078
:102090001521000015210000152100001521000068
:1020A0001521000015210000152100001521000058
:1020B0001521000015210000152100001521000048
:1020C00015210000104B1A6842F080021A600E4B76
:1020D00080229A61803A0D4B01E01A6801321A6041
:1020E0000A4B0B4A19689142F7D9074A8021D161FE
:1020F000002201E01A6801321A60044B044A196890
:102100009142E4D8F6E700BF40C00920000000106B
:102110007F1A0600FEE70000684620F007018D46A2
:1021200001B5FFF7CFFF00F03FF8164B164A9A4271
:102130000AD0002303E01449595899500433114A36
:10214000124998188842F6D3114B124A9A420AD083
:10215000002303E00F495958995004330C4A0E49A3
:1021600098188842F6D30D4B02E0002243F8042B66
:102170000B4A9342F9D300F015F8BDE801408546BB
:10218000704700BF00000010842200000000001013
:102190000000001084220000000000100000001069
:1021A00004000010FEE70000334B2022C3F8A021FA
:1021B000314BD3F8A02112F0400FF9D00322C3F81D
:1021C00004212E4A0120C3F80C01AA21C3F884205F
:1021D0005522C3F88C10C3F88C20C3F88000C3F8D4
:1021E0008C10C3F88C20244BD3F8882012F0806F19
:1021F000F9D00322C3F88020A732C3F88C20553AC7
:10220000C3F88C201C4BD3F8882012F0407FF9D003
:102210002322C3F8A420AA2132320120C3F8AC1033
:10222000C3F8AC20C3F8A000C3F8AC10C3F8AC20CE
:10223000114BD3F8A82012F4806FF9D00322C3F811
:10224000A020A732C3F8AC20553AC3F8AC200A4B03
:10225000D3F8A82012F4407FF9D009490022C3F82E
:10226000A821C3F8AC21C3F8C410C3F8C82143F2B5
:102270003A021A60704700BF00C00F4063000500BB
:04228000DE872804C9
:0400000300002000D9
:00000001FF

Initially I couldn't really tell what it was, but after looking at it carefully, I believe this is basically how it is partitioned:

AA BBBB CC [xx..xx] ??

AA refers to the number of bytes used (in hex) out of the 16 bytes starting from that particular memory location.
BBBB is the memory location in hexadecimal.
xx..xx refers to the content in the particular memory location.

I'm not so sure of the significance of CC and ?? though.

I checked the first line, i.e.
:102000000808001019210000000000000000000076
with that in memory location 0x0000 2000 (by using the read memory function in Flash Magic):
00002000 08080010192100000000000000000000 .....!..........

Every line from 0x0000 2000 to 0x0000 228F tallies with my main hex file - except the CC and ?? which I don't quite understand it's purpose.

As for the last two lines, in main hex file:
:0400000300002000D9
:00000001FF
I don't quite know what it means too.

Hence, if what was generated and what was stored in memory tallies, could it be a fault somewhere in the makefile/linker script? Or can it still be an unknown h/w fault?

[viskr]

The hex file is Intel Hex Format, google to see what the format is.

You are missing the CRC word at 0xC, and that's why the code is not starting up.

The tool chain you are using is not producing that, it may be an option in Flash Magic (did you select the proper device?)

In our GCC toolchain the code loader we use patches that location.

[az83]

Thanks viskr!

It was indeed a software problem. I used another updated start-up code and the oscillations were finally showing. Thanks once again!