Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Kremer

Pages: [1]
1
 Hi Mark

 Thanks for your suggestions my friend. Your are always helping people out. So when do you really work?  ;D

 After a hard debug session i could realize what i need was a fast flush of the allocated socket more than i ever needed in life!!! So after being slapped on face many times by the stack, i could finally achieve the perfect desired behavior by making the socket LINGER !!! This immediately flushes all socket data, buffers and whatever it takes from RAM by calling m_close. Since the client is the one who will finish the session when it get´s what´s needed, making it´s socket linger incredibly reduces the time between multiple connect/disconnect actions, and is just what i needed to run my pooling thing!!!  ;)

2
Hi

I´m developing a product that needs to run a tcp client.
Basically, this product will connect to TCP Servers (one at a time), and retrieve data from it by sending a command and receiving the data.
The code for the client is working with no problems for a single Server. I mean, it connects to a server, sends the command and receives the data, and does this loop with no problems at all.
But when i add more than one server, the problem starts to happen. Basically, it connects to the first server, sends the command and receives the data. Then it must disconnect from the current server and connect to the second server to do the same task. After finishing the last server, it must connect to the first server and repeats this process.
The problem is that, after disconnecting from the first server by calling m_close function, it connects to the second, then to the third and so on, but one time it fails and nothing happens anymore, basically because the memory is full. So i can see the m_connect function returns ENOMEM (error 18), wich means it could not allocate memory for the new control block.
When i make the socket non-blocking, this get worst, and sometimes it just can´t pass the second server.

Please, any advice is helpfull.
I´m based on the Interniche stack and coldfire lite project. I know this is not related to utasker, but any help will be very well accepted!!!

3
STTM STM32 and STR91XF / STM32F103RBT6
« on: December 18, 2007, 12:19:52 PM »
 Hi Mark

 I´d like to know if are you planning on try out those little CM3 from ST. I´m trying them now, and i really miss the ethernet part, but is nice to play around with usb interface. It seems the ST will have them in low prices so i think it will be interesting in a near future. Hope ST guys are working on some CM3 parts with ethernet phy on.

 Regards.

 Alex

4
NXPTM M522XX, KINETIS and i.MX RT / Re: SW uploads to SPI FLASH
« on: August 26, 2007, 04:46:00 PM »
 Hi Mark

 You are right assuming that is possible to have holes on it. To be honest, there are some thing´s that i still didn´t understand on this binary file.
 As an example, there are a bunch of 0x00000000 in the middle of my real application (not any example) wich i really don´t know what is. The strange fact is those sine and length words don´t appear in that 0 area and stop happening on the file before it. I think it is the .rodata area, but haven´t really worried about to decode it because i did my algorithm and it worked nice and since my goal isn´t to supply it to an end user, but for my field people wich will do the card installing, test and maintenance.
 But this week i´ll take a deep look into it and try to do a better job over it, but you know, there are many different points from project to project starting with memory configuration and on...
 Tomorrow i´ll send you the converted bin file that i didn´t sent with the raw bin on last mail, since i´m out of the office, thanks GOD :)

 Regards

5
NXPTM M522XX, KINETIS and i.MX RT / Re: SW uploads to SPI FLASH
« on: August 24, 2007, 09:14:15 PM »
 Since you don´t have the 6.4, do you need a .bin file generated by it? If you want it to start your workaround for this odd thing i can send a .bin file to you. Just give me your e mail.

 Regards

6
NXPTM M522XX, KINETIS and i.MX RT / Re: SW uploads to SPI FLASH
« on: August 24, 2007, 06:58:45 PM »
 Hi Mark

 I opened a service request on freescale and indeed there are changes on the linker from 6.4 to previous versions. I requiered a software modification on codewarrior to include on project setting configuration a filed to revert the bin generation to the old fashion way. But for now, we have to live with that, and i think you´ll need to adapt your code to deal with it.  :'(

 Here is the freescaler´s answer:
"
In reply to your Service Request SR 1-380979511:

Basically the Codewarrior for Coldfire 6.4v is based on the same compiler/linker as 6.3 but with the bunch of bugs fixed from 6.3v including on it, you can read all the bugs fixed from 6.3 in your releases notes file, installed on your Codewarrior for Coldfire/ Releases notes directory.

The main issue concerning the raw images changes, and I think this apply to your case, is the generation of raw bin image, was fixed until the 6.4 build 1 is that CWCF6.3v; The linker generates a Bin file which follows a Motorola Standard; The differences are address and length fields in the Moto image. Changes of the linker were required, for CWCF6.4

Hope this helps

Thank you for your interest in Freescale Semiconductor products and for the opportunity to serve you.

"

 Regards

7
NXPTM M522XX, KINETIS and i.MX RT / Re: SW uploads to SPI FLASH
« on: August 24, 2007, 02:53:28 AM »
 Hi Mark

 I'll try to figure out what's happening or whatever i did to generate this thing. For now take a look how it is on those jpg's.
 This is the raw bin image, wich contains the address word and the block size. This file is 127296 bytes long.



 And this is the exact file image with 123376 bytes long.


 Any news i'll post here.
 
Regards

8
NXPTM M522XX, KINETIS and i.MX RT / Re: SW uploads to SPI FLASH
« on: August 23, 2007, 01:12:25 PM »
 Hi Mark

 Actually we bought a full standard license for codewarrior and we received the 6.4. So i had to remove the 6.3 to avoid any problem. When i had 6.3 installed, i just used the BDM to flash my devices, so i hadn´t worried about the .bin contents and never took a look on it.
 On 6.4, checking the Project Settings (Alt+F7), on Linker - Coldfire Linker tab, there is a checkbox to "Generate Binary File", wich i set to generate the .bin file wich i use to generate the file image (I´m sure there is this checkbox on 6.3). Also, on the right side of this tab there is a text box to set the "Max Bin Record Length", wich gives you the size of each record block i mentioned on the previous post.
 So, my first try (because my ignorance), was to flash the exact .bin generated by CW6.4. Well, it didn´t work, so i had to scratch this .bin file and my only clue was that _SP_INIT should be the first word on that file, and the word 0x00001008 should be right after it. For my surprise, there was 2 extra words on the first 2 positions. The word 0x00001000 and 0x000000FC, then the _SP_INIT and 0x00001008 words. So i realized the first extra word was the memory position and the second word was the exact number set on "Max Bin Record Length", and they were spread over the whole file. So after removing all those words and flashing the device, everything went smooth.
 I noticed some minor differences on 6.4 from 6.3 regarding the Flash Programmer, wich now seems to do some clock checking before do something else. But maybe there are "invisible" changes on it.
 I dont know, maybe those extra information on .bin file are only inserted if the .lcf file of the compiled project tell the linker the flash doesn´t start on 0x00000000 address. In my case, my bootloader project has a .lcf with a flash start address on that position, but my main application project has it´s lcf file setting the falsh start to 0x00001000.

MEMORY
{
    program    (RWX) : ORIGIN = 0x00001000,  LENGTH = 0x0003F000
    vector_ram (RW)  : ORIGIN = 0x20000000,  LENGTH = 0x00000400
    ram        (RW)  : ORIGIN = 0x20000400,  LENGTH = 0x00007C00
}


SECTIONS
{
    ___IPSBAR           = 0x40000000;

    ___SRAM             = 0x20000000;
    ___SRAM_SIZE        = (32 * 1024);

    ___FLASH            = 0x00001000;
    ___FLASH_SIZE       = (256 * 1024);

    ___VECTOR_RAM       = ___SRAM;

.............

 Regards


9
NXPTM M522XX, KINETIS and i.MX RT / Re: SW uploads to SPI FLASH
« on: August 22, 2007, 05:15:23 PM »

It then copies the new code to its operating position before again checking its contents to ensure that there was no error during the copy. Only then will it delete the backup of the code so that it doesn't try to load it again at the next reset.


 Hum, i don´t do a second checksum after flashing the internal coldfire flash. I think is better do it to be sure the code was correct copied from serial flash to internal flash. Nice!!! ;)
 I´m using CRC and some guardwords to ensure there is a valid code on serial flash, like you mentioned, but the transfer and serial flash contents are not encrypted like you did, so the serial flash holds the exact program image contents. Maybe i should modify it too.
 In my case, i developed a c++ program that opens a .bin file generated by the compiler i use (CW 6.4) and build the exact file image from this .bin file, wich isn´t the exact file image since it holds extra information including an address word and a block size word, for each code block in the file, so copying the exact .bin generated by codewarrior to internal flash doesn´t work. After doing it, the user can open an ethernet connection with the card and send the file image. It´s really fast.
 I think these extra information words were implemented to guide the flash programmer routine in codewarrior software. I don´t know if you know what i´m talking about, since i don´t know if you use codewarrior too. Anyway, now my product is pretty decent, so thanks for the help again.

 Regards

10
NXPTM M522XX, KINETIS and i.MX RT / Re: SW uploads to SPI FLASH
« on: August 22, 2007, 03:34:49 PM »
 Hi Mark

 Thank you for the help supplied on freescale´s forum about my bootloader question.
 Finally i had time to do it and this topic shows exactly what i did here.
 I did the bootloader using the same ammount of flash you used (0x1000) and the user code is stored by the user application on a SPI serial flash (m25P40 from ST), so it´s able to store full 256K of user program, like you already said, minus bootloader size (4K).
 I have one question. In your code, the serial flash load with user code to be flashed into CF internal flash is user code responsibility or your bootloader has an ethernet code wich handles the transfer between a binary file from a PC to the serial flash, and after do it it flashes de internal memory?
 In my case, the user code is responsible for load the serial flash, and the bootloader only checks the serial flash and then flash the internal memory.
 The thing works smoothly. Thank you.

 Regards

11
NXPTM M522XX, KINETIS and i.MX RT / Congratulations
« on: July 09, 2007, 01:18:45 PM »
 Hi Mark

 I didn´t resist to first post on MCF5223X forum  :)
 Congratulations for all the really good work with/to this micro controller and keep up this good job.
 I hope this forum can help many users and bring answers to those who need.

 Success

 Regards

Pages: [1]