Printf() in IAR EMbedded Workbench

I cannot see your image, but I'm guessing here...

teh problem is that char __code * most likely is a 20 bit pointer into code flash. printf, however, expects a 16 bit pointer. By your cast, you removed the upper 4 bits from the pointer, which compiles fine but won't pass the pointer to the string to printf. Instead a completely different reggion in the lower 64k is pointed to. And it contains the garbage you see.

You can't eat the cake and keep it. If you want to pass something to prntf, it must be in the lower 64k. Period.

Hi Gross,

Thanks for your Help.

But whenever I use printf() it gives that error (means for printing a simple string like printf("HELLO"); too) . I'm declaring variable/pointer as unsigned short and still it is showing char_code * mismatch. SO is there any way to bring variable in to lower 64k period.???

Please  help me.

Thanks and regards,

Nagabhushan

Further Information::

I'm Using cod model as Near and data model as Large. Also I have attached snapshots of my settings here.

Thanks,
nagabhushan

Nagabhushan Naik said:

data model as Large

Yes. That's the problem, as I already wrote. Large data model means that data is placed everywhere in the 20 bit addressing range. Especially constant strings are placed above 64k, such as the format string you use for printf.

And printf only accepts 16bit pointers, pointing into the lower 64k. hence the compiler error: your format string is (due to large data model) placed in the flash above 64k, adn has a 20 bit pointer. By typecasting, you cut off the upper 4 bits and create a 16 bit pointer, but it no longer points to the string.

e.g. the string is placed at 0x18000. So the char _code * is a 20 bit value 0x18000. By typecasting it to char * you cut off the upepr 4 bits. Not it is a 16 bit pointer, accepted by printf, but it now points to 0x08000 and no longer to 0x18000 where the string is.

Unfortunately, there is no simple solution to this, except for not using the large data model.
The non-simple solutoin would be to 1) define the strings as global constants rather than writing them in the printf function call directly, and 2) ensure that the constants are placed in the lower 64k by using the proper #pragmas.

Thanks for your Help Gross.

Thanks,

Nagabhushan

Hello,

How one can see the outcome of Printf() in order for me to debug my C code on IAR for the cc2540 ?
I use the instructions in this link (statusbits.wordpress.com/.../) but it doesn't work for me, because I need instructions for cc2540!!!
Please help me. if you know!

Thank you very much in advance,

Emocs said:

How one can see the outcome of Printf()

In general, printf() sends each single character it creates to the putchar() function.

How it is implemented depends on your system.
On some systems (e.g. NutOS for the ATMega128-based Ethernut) you need to initialize stdout stream, on some systems (liek typical PC OS), the OS has already done this.
On the MSP430, it is an empty function that you can overwrite with your own implementation that takes a byte and does with it whatever you want (e.g. sending it through UART).

Some IDEs place a breakpoint on putchar, fetch the passed parameter (the data byte) through JTAG and show it in a console window (while the putchar() function itself remains empty).

If you use sprintf() instead of printf(), you pass it a pointer to a buffer as first parameter. As a result you'll get a string (written to this buffer) that contains the generated text, and you can do with it whatever you want.