Scrum master needs to be technical? Developers look down upon him or not involve in meetings thinking he can contribute anything. How to change the mindset.?

A Scrum Master does not need to be technical.   I believe I perform well in the Scrum Master role (based on team feedback and improvement), but I am no longer "technical" by any stretch.

Outside of that Rhea, you need to provide more context about your situation before I can reply.

There have been various times that the developers dont understand why a scrum master is needed. They are not explicit in this thought but thats the vibe.

They usually don't put us in the meeting invite thinking that we won't be able to contribute much in the discussions and are ok to continue with the sessions even when we decline or propose new time saying that we can have the meeting without you. 

Personally, I believe that it is extremely beneficial for a Scrum Master to be technical.

In general, agile coaching exists at three levels - team, cross-team (program, etc. - there may be different levels of this cross-team work in an organization, depending on scale), and organizational. Someone working in one level will often have to cross levels in order to perform their function, but the emphasis tends to be on enabling success at a particular level. A Scrum Master works primarily at the team level, but will take on some cross-team work when applying scaling and has responsibilities to the organization and other stakeholders to enable the team to effectively use Scrum.

The Agile Coach Competency Framework defines a four quadrants that someone in a coaching role should have some level of competency in. The interesting one is the Mastery quadrant. There are four types of mastery - Technical, Business, and Transformation. Someone working primarily at the team level (such as a Scrum Master) will probably face more technical challenges, so should be stronger in the Technical Mastery. However, that doesn't mean that the Scrum Master can't avoid developing or having some competence in Business and Transformation. As the coach changes the level at which he or she is working, the competencies change - someone working across teams will probably need more business and transformation skills than technical skills and someone working across a large enterprise will definitely need more transformational and business skills.

In a software development organization, I'd also turn to the principles behind the Manifesto for Agile Software Development. Enabling some of these principles is aided by having a technical background. Being a champion of the lean and agile values and principles is part of any agile coaching role, including that of Scrum Master. If you don't have sufficient technical background, you can't speak with authority with respect to some of these principles, such as methods and practices to enable frequent delivery of working software or continuous attention to technical excellence. But that doesn't mean that you can't teach the team from examples of why these things are beneficial.

But just because it's beneficial for a Scrum Master to be technical doesn't mean that a non-technical person can't contribute to the success of the team in creating and rolling out a lean-agile approach. I don't think that a team should look down upon a non-technical Scrum Master. The Scrum Master should, however, recognize their strengths and weaknesses and work with the team to enable them in the best possible manner.

It all depends on the team. It also depends on the level of technical ability is expected. A SM is supposed to be a master of Scrum, not of the technical aspect of a specific product. Sure it helps when the SM has that context but I would take a SM that is a master in Scrum over one that has mastery in the technical side of things with a low understanding of Scrum and Agile. 

Now, should the SM strive to learn more about the product they are supporting? Sure. I think the SM should have a high-level understanding of the technical aspects of the product but I don't think the SM needs to know how to actually write the code for the product. In my experience, the technical mastery is a "nice to have" in a Scrum Master position but does not make or break one's ability to serve the team in the SM role. 

I know a number of Scrum Masters that transitioned from manual testing QA roles.  While they have some technical abilities and understand the challenges they do not have the skills to write code.  I do think that if the Scrum Master is on a technical team, having at least a high level understanding of the work the team does helps in their efforts to create a high-performing, self-managing team.  If the team is less technical such as marketing, human resources, etc, then having a "technical" understanding of the jobs that team undertakes is also beneficial.  

While I say all of the above I do not feel that technical knowledge is absolutely necessary.  I know of an member of an HR organization that holds a CSM.  They have dealt with a team of developers as Scrum Master.  

It ultimately comes down to whether the teams understands your role and respects you for the skills you.  Sometimes it takes a lot of effort on the Scrum Master's part to establish themselves.  In that case, the Scrum Master should look at what is causing the lack of trust or misunderstanding and work with them to prove themselves. And in some cases it might take admitting your limits and asking for help to increase your value to the team.  In my experience, Developers are somewhat vain and really like it when someone asks them to explain things to so that they can understand.  They may grumble and groan about it, but underneath all the noise they actually like that you asked.